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(57) Abstract 

An object oriented programming 
(OOP) based messaging interface method 
for use between a client application and a 
messaging service on a computer system is 
provided. The method includes providing: 
a message class which has data members 
and member functions related to a message 
in the messaging service, a message bin 
class which has data members and member 
functions related to holding the message, 
and a message bin name class which 
has data members and member functions 
related to identifying a message bin object 
instantiated from the message bin class. 
Subsequently, a messaging interface object 
for the message is generated as an instance 
of one or more of the provided classes. 
This generated messaging interface object 
furnishes the client application with protocol 
independent access to the messaging service. 
In addition, a storage device readable by 
a computer system for implementing the 
(X)P-based messaging interface method 
and an OOP-based messaging interface are 
provided. 
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AN OBJECT ORIENTED PROGRAMMING BASED MESSAGING INTERFACE SYSTEM AND METHOD 

Field Of The Invention 

Tne present invention relates generallv to a messaging interface 
to an electronic messaging system for a communication network. More 
particularly, the present mvennon relates to such a messaging interface 
as implemented in an object oriented programming based 
10 en\'ironment. 

Background of the invention 

A vanetv of different messaging systems are known which are 

13 used to transrer data between different users connected to a common 

network. For example, a number of electronic mail svstems are used to 
exchange mail message between human users typically connected to 
some form of a communication network via a personal computer. Use 
or such messaging systems are increasingly used m a number of 

20 environments over a wide variety of different type of networks. 

The types of users connected to the network are also mcreasingly 
adding complexity to the network. For example, one user may be 
connected to the network via one type of computing platform while 
anotner user mav use a different type of computing platrorm. This 

Id places an increased burden on the messaging svstems to handle 

messages generated usmg different software and hardware having 
different messagmg protocols. 

Moreover, multiple network systems are being increasingiv tied 
together (e.g., the Internet), effectively formmg larger networks 

30 connectmg systems using even more disparate hardware and software. 
Tne messagmg systems may be either directly connected to the system 
using a gateway to allow messages to be routed between the different 
systems, or indirectly connected (i.e., messagmg systems which 
communicate through a third system and which are not directly 

35 connected to the same third svstem). 

Current messaging systems are unable to efficiently handle 
messagmg between the various types of user systems. As a result, the 
ty-pe of data which may be transferred must be limited to common 
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rormats (e.g., ASCII text) to be handled by the different system. The data 
to be transrerred across such heterogeneous environments looses 
fideiitv as a result or' translations and transrormations to the lowest 
com.mon denommator capable or bemg handled bv the different 
5 systems. Proper messaging over such disparate systems is also hmdered 
by different message protocols. For example, there mav be several vvavs 
to address a single recipient, adding still further compiexin- to the 
system. 

In order to address the above problems, attempts ha\-e been made 
10 to provide application programs capable or operating on different user 
systems and freely exchanging messages therebetween. Such 
approaches attempt to specifically address the different types or svstems 
being used to provide messagmg capabilities. -Vnother approach is to 
standardize or limit the types of messaging systems used on a network. 
15 This, however, limits the functionality of the network and the 
messagmg systems. 

Object oriented programming (OOP) has become increasingh' 
used to develop complex applications. As OOP moves toward the 
mainstream of software design and development, electronic messagmg 
20 svstems, like e-mail, will need to be adapted to make use of the benefits 
of OOP. A need exists for these principles of OOP to be applied to a 
messagmg interface of an electronic messaging system such that a set of 
OOP classes and objects for messagmg interface can be provided. 

OOP is a process of developing computer software usmg objects, 
25 mcludmg the steps of analyzing the problem, designing the system, and 
constructing the program. .An object is a software package that contains 
both data and a collection of related structures and procedures. Since it 
contains both data and a collection of structures and procedures, it can 
be visualized as a self-sufficient component that does not require other 
30 additional structures, procedures or data to perform its specific task. 
OOP. therefore, views a computer program as a collection of largely 
autonomous components, called objects, each of which is responsible 
for a specific task. This concept of packaging data, structures, and 
procedures together in one component or module is called 
35 encapsulation. 

OOP components, in general, are reusable software modules 
which present an interface that conforms to an object model and which 
are accessed at run-time through a component integration architecture. 
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A component integration architecture is a set or architecture 
mechanisms u-hich allow software modules in different process spaces 
to utilize each other s capabilities or functions. This is generallv done bv 
assuming a common component object model on which to build the 
architecture. 

It is xvorthwhile to differentiate between an object and a class of 
objects at this point. An object is a single instance of the class of objects, 
which is often just called a class. A class of objects can be viewed as a 
blueprint, from which many objects ran be formed. 

OOP allows the programmer to create an object that is a part of 
another object. For example, the object representing a piston engine is 
said to have a composition-relationship with the object representmg a 
piston. In realitv.. a piston engine comprises a piston, valves and many- 
other components; the ract that a piston is an element of a piston engine 
can be iogicaliv and semanhcallv represented in OOP by r^vo objects. " 

OOP aiso allows creation or an object that "depends rrom" 
another object. If there are two objects, one representing a piston engine 
and the other representmg a piston engine wherein the piston is made 
of ceramic, then the relationship between the two objects is not that of 
composition. A ceramic piston engine does not make up a piston 
engine. Rather it is merely one kind of piston engine that has one more 
limitation than the piston engine; its piston is made of ceramic. In this 
case, the object representing the ceramic piston engine is called a 
derived object and it inherits all of the aspects of the object representmg 
the piston engine and adds further limitation or detail to it. The object 
representing the ceramic piston engine "depends from" the object 
representing the piston engine. The relationship between these objects 
is called inheritance. 

When the object or class representing the ceramic piston engine 
ir^hents all of the aspects of the objects representing the piston engine, it 
inherits the thermal characteristics of a standard piston defined in the 
piston engine class. However, the ceramic piston engine object 
overrides these thermal characteristics with those specific to a ceramic 
piston xvhich are typically different from those associated with a metal 
piston. It skips over the original and uses new functions related to 
ceramic pistons. Different kinds or piston engines ^vill have different 
characteristics, but may have the same underlying functions associates 
with it (e.g., how many pistons in the engine, ignition sequences. 
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lubrication, etc.}. To access each ot these functions in anv piston engine 
object, a programmer would call the same functions with the same 
names, but each type of piston engine may have different /overriding 
implementations of functions behind the same name. This abilitv to 
5 hide different implementations ot a function behind the same name is 
called polymorphism and :t greatly simplifies communication among 
objects. 

With the concepts of composition-relationship, encapsulation, 
mhentance and polymorphism, an object can represent just about 
10 anything m the real world. In fact, our logical perception or the reaiitv 
IS the only limit on determining the kinds of things that can become 
objects in object-oriented software. Some typical categories are as 
follows: 

• Objects can represent physical objects, sucn as automobiles m a traffic- 
15 flow simulation, electrical components in a circuit-design program. 

countries m an economics model, or aircraft m an air-traffic-control 
svstem. 

• Objects can represent elements of the computer-user environment 
such as windows, menus or graphics objects. 

20 • An object can represent an mventory, such as a personnel file or a 
table of the latitudes and longitudes of cities. 

• An object can represent user-defined data types such as time, angles, 
and complex numbers, or point on the plane. 

25 With this enormous capabilitv of an obiect to represent just about 

any logically separable matters, OOP allows the software developer to 
design and implement a computer program that is a model of some 
aspects of reality, whether that reality is a physical entitv, a process, a 
s\'Stem, or a composition of matter. Since the object can represent 

30 anvthing, the software developer can create an object which can be used 
as a component m a larger software project m the future. 

If 90% of a new OOP software program consists of proven, 
existing components made from preexisting reusable objects, then only 
the remaining 10% of the new software project has to be written and 

35 tested from scratch. Smce 90% already came from an inventorv- of 

extensivelv tested reusable objects, the potential domain from which an 
error could originate is 10% of the program. As a result, OOP enables 



MSDOCID; <WO 9722928A1J_; 



SUBSTITUTE SHEET (RULE 26) 



wo 97/22928 PCT/US96/20536 

sortware developers to build objects out or other, Dreviouslv built, 
objects. 

This process closely resembles compiex machinerv being built out 
Of assemblies and sub-assemblies. OOP technology, therefore, makes 
5 software engmeering more like hardware engmeermg m that software 
is built from existing components, which are available to the developer 
as objects. All this adds up to an improved qualitv of the software as 
u'ell as an increased speed of its development. 

Programming languages are beguir.mg to fully support the OOP 

10 principles, such as encapsulation, inheritance, polymorphism, and 

com.position-relationship. With the advent of the C++ language, many 
commercial sortware developers have embraced OOP. C-t-t- is an OOP 
language that offers a fast, machine-executable code. Furthermore, C-r-r 
IS suitable for both commercial-application and systems-programming 

15 proiects. For now, appears to be the most popular choice amonR 

many OOP programmers, but there is a host of other OOP languages, 
such as Smalltalk, common lisp object system (CLOS), and EiffeL 
Additionallv, OOP capabilities are being added to more traditional 
popular computer programming languages such as PascaL 

^0 The benefits of class libraries can be summarized, as follows: 

• Objects and their corresponding classes break down complex 
programming problems into many smaller, simpler problems. 

• Encapsulation enforces data abstraction through the organization of 
data into small, independent objects that can communicate with each 

25 other. Encapsulation protects the data in an object from accidental 

damage, but allows other objects to interact with that data bv calling 
the object s member functions and structures. 

• Subclassing and inheritance make it possible to extend and modify 
objects through deriving new^ kinds of objects from the standard 

30 classes available in the system. Thus, new capabilities are created 

without having to start from scratch. 

• Polymorphism and multiple inheritance make it possible for 
different programmers to mix and match characteristics of many 
different classes and create specialized objects that can still work with 

35 related objects in predictable wavs. 

• Class hierarchies and containment hierarchies provide a flexible 
mechanism for modelmg real-w^orld objects and the relationships 
amone them.- 
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These libraries or reusable classes are userul in manv situations, 
bur they also have some limitations. For example: 

• Complexity. In a complex system, the class hierarchies ror related 

5 classes can become extremely confusing, with manv dozens or even 

hundreds ot classes. 

• Flow of control. A program written with the aid of class libraries is 
still responsible for the flow of control (i.e., it must control the 
interactions among all the objects created from a particular librarv')- 

10 The programmer has to decide which functions to call at what times 

for which kmds of objects. 

• Duplication of effort. Although class libraries allow programmers to 
use and reuse many small pieces of code, each programmer puts 
those pieces together in a different wav. Two different programmers 

15 can use the same set of class libraries to write two programs that do 

exactly the same thing but whose internal structure (i.e., design) may 
be quite different, depending on hundreds of small decisions each 
programmer makes along the way. Inevitably, similar pieces of code 
end up doing similar things in slightly different wavs and do not 

20 work as well together as thev should. 



Class libraries provide lots of tlexibilit\-. As programs grow more 
complex, m.ore programmers are forced to reinvent basic solutions to 
basic problems over and over again. A relati\ elv new extension of the 

25 class librarv idea is to have a framework of class libraries. This 

rramework is more complex and consists of significant collections of 
coilaboratmg classes that capture both the small scale patterns and 
major m.echanisms that implement the common requirements and 
design in a specific application domain. They were first developed to 

30 free application programmers from the chores involved in displaving 
menus, windows, dialog boxes, and other standard user mterface 
elements for personal computers. 

Frameworks also represent a change in the wav programmers 
thmk about the interaction between the code thev write and code 

35 u*ntten by others. In the early days of procedural programming, the 
programmer called libraries provided bv the operating svstem to 
perform certain tasks, but basically the program executed down the page 
from start to finish, and the programmer was solelv responsible for the 
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10 



How ot control. This was appropriate tor printing out pavchecks, 
calculating a nr;athematical table, or solving other problems with a 
program that executed in iust one wav. 

The development or graphical user interfaces began to turn this 
procedural programming arrangement inside out. These interfaces 
allow the user, rather than program logic, to drive the program and 
decide when certain actions should be performed. Todav, most personal 
computer soft%vare accomplishes this by means of an event loop which 
monitors the mouse, keyboard, and other sources of external events and 
calls the appropriate parts of the programmer s code according to actions 
that the user performs. The programmer no longer determines the 
order m which events occur. Instead, a program is divided into separate 
pieces that are called at unpredictable times and in an unpredictable 
order. 3v relinquishmg control m this wav to users, the developer 
15 creates a program that is much easier to use. Nevertheless, individual 
pieces or the program written by the developer still call libraries 
provided by the operating system to accomplish certain tasks, and the 
programmer must still determine the rlow of control within each piece 
after it s called by the event loop. .Application code still "sits on top of 
20 the system. 

Even event loop programs require programmers to write a lot of 
code that should not need to be written separately for every application. 
The concept ot an application rramework carries the event loop concept 
rurther. Instead of dealing with all the nuts and bolts of constructing 

25 basic m.enus. windows, and dialog boxes and then making these things 
all work together, programmers using application frameworks start 
with working application code and basic user interface elements in 
place. Subsequently, they build from there by replacing some of the 
generic capabilities of the framework with the specific capabilities of the 

30 intended application. 

Application frameworks reduce the total amount of code that a 
programmer has to write from scratch. However, because the 
framework is really a generic application that displays such as windows, 
supports copy and paste, and so on, the programmer can also relmquish 
3d control to a greater degree than event loop programs permit. The 
rramework code takes care of almost all event handling and flow of 
control, and the programmer s code is called only when the framework 
needs it (e.g., to create or manipulate a proprietary data structure). 
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'■^ programmer writing a rramework program .not onlv 
relmquishes control to the user tas is also true for event loop programs}, 
but also relmquishes the detailed flow ot control within the program to 
the framework. This approach allows the creation of more complex 
5 systems that work together m interesting wavs, as opposed to isolated 
programs, having custom code, being created over and over again for 
similar problems. 

A framework basically is a collection of cooperating classes that 
make up a reusable design solution for a given problem domam. It 
r\-pically includes objects that provide default behavior (e.g., menus and 
windows), and programmers use it by inheriting some of that default 
behavior and overriding other behavior so that the framework calls 
application code at the appropriate times. 

There are three mam differences between frameworks and class 
1? libraries: 

• Behavior versus protocol. Class libraries are essentiallv collections of 
behaviors that you can call when you want those individual 
behaviors in your program. A framework, on the other hand, 
provides not only behavior but also the protocol or set of rules that 

20 govern the ways m w^hich behaviors can be combined, including 

rules for what a programmer is supposed to provide versus what the 
framework provides. 

• Call versus override. With a class librarv, the code the programmer 
writes instantiates objects and calls their member functions. It's 

25 possible to instantiate and call objects in the same wav with a 

framework (i.e., to treat the framework as a class library), but to take 
full advantage of a framework s reusable design, a programmer 
typically writes code that overrides and is called bv the framework. 
The framework manages the flow of control among its objects. 

30 Writing a program involves dividing responsibilities among the 

various pieces of software that are called by the framework rather 
than specifymg how the different pieces should work together. 

• Implementation versus design. With class libraries programmers 
reuse only implementations, whereas with frameworks they reuse 

35 design. A framework embodies the way a family of related programs 

or pieces of software work. It represents a generic design solution 
that can be adapted to a varietv of specific problems in a given 
domam. For example, a single framework can embodv the wav a user 
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intcrfacc works, even though two different, user interfaces created 
with the same framework might solve quite different interface 
problems. 

5 Thus, through the development of frameworks for solutions to 

\ anous problems and programming tasks, significant reductions in the 
design and development effort for software can be achieved. 

A more detailed description of OOP is given bv Cotter, et ai, 
Inside Talieenr Technology. Addison-VVesiey Publishing (1995). 

Incorporation of the principles of OOP in a messagmg interface 
allows the messaging svstem to be more tightlv integrated with other 
OOP-based applications and operatmg systems. In addition, the 
maintenance and development effort required bv such an OOP-based 
m-essagmg interface will likely be significantly less than complex 
15 procedural programming-based messaging mterraces. This is because 
parts (i.e., objects or classes) of the OOP-based messaging mterface may 
be modified as needed and automatically propagated throughout the 
software code without affectmg the rest of the messaging mterface. In 
contrast, an entire procedural programmmg-based messagmg interface, 
20 as conventionaiiv produced, must be completely tested and debugged 
each time any modification is made to the software code, because each 
modification must be manually propagated to different parts of the 
software code. 

The present mvention provides a solution to these and other 
2d problems, and orfers other advantages over the prior art. 

Summary of the Invention 

The present mvention relates to an OOP-based messaging 
30 interface between a client application and an electronic messaging 
systemi. 

In accordance with one aspect of the invention, a messaging 
interface between a client application and a messaging service for a 
computer svstem is provided. The messagmg mterface includes a 
35 storage device, m the computer system, which stores OOP-based classes. 
These stored classes include: a message class which has data members 
and member functions related to a message in the messagmg ser\-'ice, a 
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message bin class which has data members and member functions 
related to holding the m.essage, and a message bm name class which has 
data members and member functions related to identifying a message 
bm obiec: mstanriated from the message bin class. The messaging 
5 interface also includes a processor operativelv coupled to the storage 
device which generates a messagmg mterface object for the message as 
an instance of one or more of the stored classes. This generated 
messaging interface object furnishes the client application with protocol 
independent access to the messaging service. 

^0 This aspect of the invention also can be implemented as an OOP- 

based messaging interface method for use between a client application 
and a messagmg service on a computer system.. This method is 
performed by device-implemented steps in a series of distinct processing 
steps that can be implemented in one or more processors. A message 

15 class which has data members and member functions related to a 

message m the messagmg service is provided. Also, a message bm class 
which has data members and member functions related to holding the 
message is provided. In addition, a message bm name class which has 
data members and member functions related to identifvmg a message 

20 bin object instantiated from the message bm class is provided. A 

messagmg mterrace object for the message is generated as an instance of 
one or more of the provided classes. This messaging interface object 
furnishes the client application with protocol independent access to the 
messaging service. 

These and various other features as well as advantages which 
characterize the present invention will be apparent upon reading of the 
following detailed description and review of the associated drawings. 

Brief Description of the Drawings 

30 

FIG. 1 IS a block diagram of a personal computer system in 
accordance with a preferred embodiment of the present invention. 

FIG. 2 IS a block diagram of a route a message might take from an 
originator to a recipient. 

5- FIG- 3 is a block diagram showmg the transport of data through a 

messagmg system. 

FIG. 4 is a block diagram of a typical messagmg svstem. 
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FIG. 5 IS a block ciiagram or components ot a preferred 
embodiment messaging system architecture. 

FIG. 6 is a block diagram ot a preferred embodiment object 
oriented programming based messagmg interface used in the computer 
svstem shown in FIG. 1. 

FIG. 7 is a block diagram of the ciass hierarchy for the preferred 
embodiment messaging interface. 

FIG. S IS a block diagram of an example life-cylce of a message m 
the messaging svstem. 

FIG. 9 is a block diagram of the class hierarchy for the preferred 
embodiment message bin classes. 

FIG. 10 IS a block diagram of the ciass hierarchy for the preferred 
embodiment message bin name classes. 

FIG. 11 is a block diagram of the class hierarchy for the preferred 
embodiment message classes. 

FIG. 12 IS a flowchart of the preferred embodiment object oriented 
programming based messaging interface method used in the computer 
system shown m FIG. 1. 

Detailed Description 

The preferred embodiment of the present mvention is preferably 
practiced in the context of an operating system resident on a personal 
computer such as the IBM® PS/2® or Apple® Macintosh® computer. 
■A representati'.-e hardware environment is depicted in FIG. 1, which 
iiiustrates a t\-pical hardware configuration of a workstation m 
accordance with the preferred embodiment having a central processmg 
unit 110, such as a microprocessor, and a number of other units 
interconnected via a system bus 112. The workstation shown in FIG. 1 
includes a Random Access Memory (RAM) 114. Read Onlv Memorv 
(ROM) 116. an I/O adapter 118 for connecting peripheral devices such as 
disk storage units 120 to the bus 112. a user mterface adapter 122 for 
connecting a kevboard 124. a mouse 126. a speaker 128, a microphone 
132, and /or other user interface devices such as a touch screen (not 
shown) to the bus 112. communication adapter 134 for connectmg the 
workstation to a communication network (e.g.. a data processing 
network) and a display adapter 136 for connecting the bus 112 to a 
display device 138. The workstation typically has resident thereon an 
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. operating systenn such as the IBM OS/2® operating svstem or the Apple 
5vstem/7® operating systenn. 

Store and forward messaging is a class of communication 
involving asynchronous transmission and reception of data. 
5 Asynchronous communication allows message transfer even when the 
originator and the recipient are not simultaneouslv active. TTie term 
^'messaging" sometimes will be used hereinafter for store and forward 
messaging. 

FIG. 2 is a block diagram showing a route that a message might 

10 take from an originator 200 to a recipient 204, 208. TTtis route is not 
usually specified in the message, but is determined by the messaging 
system. The originator 200 creates the message and submits it to the 
messagmg system. The message is made persistent locaiiv. 
The message is then forwarded to the next hop and made persistent 

15 there at the intermediate node 206. This processes of persisting and 
forwarding is repeated between the intermediate node 206 and 
recipient2 208. The message is received by the recipient. At this tu7\e, 
the message m.ay or may not persist after this point; however, usuallv it 
does persist. A copy of the message may similarly be delivered to 

20 Recipient 1 204 through some intermediate nodes 202, 

It is important to note that messages persist (i.e., are stored), and 
that the\' may be forwarded several times before reaching their 
destination. If any of the intermediate links are down, the message is 
held at that hop until the next hop can be reached. This is a basic 

25 description of store and forward messaging, including: 

Store and forward messaging has manv advantages: 

• All of the nodes along the route do not have to be up 
simultaneously. 

• The originator does not need to be directly connected to the recipient. 
30 • Timing is less restricted, so translation at intermediate nodes is more 

feasible, allowing for interconnection of different messaging svstems. 

• Messages are held in a persistent state and are therefore more 
immune to failures. 

35 Store and forward messagmg also has the following drawbacks: 

• Failures can occur asynchronously with respect to submission context 
forcing more complicated error reporting and status interrogation 
machmerv. 
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• Timing is unpredictable. 

• Gateways and translation mav result in loss of data fideiitv. 

• Reception is not guaranteed. 

• Error reporting generally uses messaging racilities as well, so error 
notifications mav be lost. 

• Retransmission unit is usually the whole message, which can be 
quite large. 

► Intermediate hops must have persistent storage available. 

► -Messages are handled by entities who are not the origmator and 
recipient, opening a potential security hole in the system. 

• Since the connectivity is not direct, originators mav need help in 
rinding recipients, either bv being explicitly told of their existence or 
by browsing some directorv. 

15 In general, messages can carrv any data. In practice, as shown in 

FIG. 3, many messaging systems are restricted to carrying a te.xt stream 
from a limited character set. This is a consequence of the fact that many 
messagmg systems had their roots in facilities designed to provide 
electronic mail between human users. Electronic mail is still one of the 

20 mam clients of messagmg, and many messaging services are in fact 
implemented on the remnants of old e-mail svstems. 

As a result of this, messages containing non-te.xt data mav need to 
be encoded when sent using older messaging systems. In addition, the 
capacities of these older mail systems are based on I960's and 1970'5 

-5 technology, which mav limit the maximum message size (i.e.. messages 
larger than this size may be truncated, dropped or bounced back). 

Because of the ability to gateway systems together, the picture of 
the messaging systems of today and the near future may be even more 
complicated. It is possible to join heterogeneous systems in manv 

30 different combinations. This is very common in today's business 

environments. For example. FIG. 4 sho%vs a typical messaging svstem. 
At least three different messagmg systems are depicted here. Some are 
directly connected, meaning that some form of gatewav exists between 
them and that at least some messages are capable of being routed 

35 between the different svstems. An example of this is QuicldVIail 400 and 
internet 402. Others are indirectly connected, meaning that thev are 
directly connected to the same third system. .An example is 
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Compuserve 404 and QuickMaii 400 being indirectlv connected through 
Internet 402. 

Several important pomts to remember about heterogeneous 
environments are: 

• Connectivitv (direct and especially indirect) of different messagmg 
systems mav result in loss of data fidelitv due to translations and 
transformations. 

• Tnere may be several ways to address a recipient. 

• A single workstation may participate m multiple messaging systems. 

• Difrerent systems offer different services and guarantees about those 
services- Requests made of one system may not be honored bv 
another. This can happen without the originator's knowledge or 
permission. 

15 The present invention provides an interface or a front end to such a 
messaging svstem. The interface presented m the following sechons 
attempts to provide choices to clients to ensure the level of integrity and 
interoperability desired. The interface achieves the following goals: 

• The interface is protocol independent (e.g., it is not specifically 
designed for use with only the Internet or some other electronic mail 
system ). 

• The interface supports any content type. 

• The interface supports propertv-based message filtermg. 

• The underlvmg framework supports multiple messaging protocols. 

• The underlvmg framework allows implementations of multiple 
messaging protocols to be concurrently active. 



20 



25 



30 



FIG. 5 shows the components of a preferred embodiment 
messaging system architecture. The messaging interface 500 is a set of 
classes that client applications (e.g.. E-mail 502 and Groupware 
Applications 504) use to access messagmg features. The messagmg 
framework 506 is a set of classes which provide the functionality 
specified by the messaging interface 500. A service provider plugs into 
the framework 506 and provides an implementation for functionality 
35 that IS specific to a messagmg protocol or a storage structure. Three 

service providers are shown, including: Simple Mail Transfer Protocol 
fSMTP) 508, cc:mail 510, and X.400 512. 
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The messaging interface 500 communicates between a client 
application (e.g.. E-mail 402) and a messagmg service for a computer 
svsrem te.g., a messagmg framework 406). .An exampie of how this 
messagmg interlace 500 might be implemented is an OOP-based 
5 environment is shown m FIG. 6. A storage device (e.g., RAM 114, ROM 
116. and /or hard disk 120) stores object oriented programming based 
classes. The basic functions which need to be embodied in classes are 
data members and member functions related to: a message in the 
messaging service, a bin for holding the message, and mechanism for 
10 identifying a message bm. These functions can be stored in one or more 
classes. In this example, each of these functions is in a different class 
(i.e., class 1. class 2, and class 3). A processor 110 retrieves classes from 
the storage device 114 and generates a messagmg interface object for the 
message as an instance of the retrieved class. This generated messagmt^ 
15 interrace object alone or in conjunction with other generated objects 

furnishes the client application with protocol independent access to the 
messaging service. By usmg high-level objects, communications from 
the client applications can be generalized for any service provider or 
communications protocol. These generalized communications are then 
20 interpreted by the underlying messagmg framework and converted to a 
compatible format before sending them to the ser\ace provider (e.g., an 
Internet service provider). Similar conversions are done by the 
messaging fram.ework through the messaging interface in the receiving 
direction so that both directions of communication are seamless to the 
25 client applications. 

The following description is focused on the messaging interface 
classes and general design principles used in applying them. 

FIG. 7 shows the class hierarchy for the preferred embodiment 
messagmg interface. The class tree consists of many abstract classes 
needed to provide clear demarcation of behaviors and concrete classes 
that client applications can directly use. The concrete classes are shown 
with bold and italic text in this and the following figures. 

Appropriate interface classes are multi-thread safe for client 
application's usage, but some classes are not. Later sections will describe 
each class in detail and specify whether or not it has thread-safetv. 

Issues of ownership of a heap-allocated object can be quite 
problematic- The messaging interface classes are generallv reference- 
counted, and manipulation of objects is through the safe-pointer objects 



30 
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to memory locations. This design trees messaging client applications 
from the responsibility of storage-deallocation and thus is considered 
memory safe. 

The messaging interface has manv classes that act on behalf of a 
5 real object - in some cases persistent objects (e.g., messages, message 
boxes, etc.)- The later sections will identify these classes as surrogate 
classes. The classes that stand for themselves are labeled vaiue-like. 
One important difference a client application might notice between 
surrogate and value-like classes is that an operation on a surrogate 

10 object may fail due to the demise of the real object backing it. For 

example, the command "get subject" operation on a message object will 
fail, if the message object instance it is referring to has been deleted. 

The objects in TMessage hierarchy are thin handles with hidden 
master objects behind them. Hence these objects are cheap to copy. 

1? Different classes in TMessage 724 hierarchy represent a message at 

different stage m its life-cycle through the messaging svstem. 
TDraftMessage 726 part of the tree represents the messages m 
construction. These messages are not yet submitted for the deliverv and 
allow adding data and messagmg attributes to them. 

20 T\lessageReference 712 on the other hand represent a message that has 
been either submitted or received and hence immutable. FIG. 8 shows 
the life-cycle of a message. Also, since message classes other than 
TMessageReference 712 are used for construction only, thev can not be 
copied. This means that only one copv of a particular draft message 

25 exists at a time thus avoiding conflicting access to same message. 

The basic concept and behavior for all the interface classes of the 
preferred embodiment are described in the following section. A simple 
basic attributes table is provided for every class. This table provides a 
quick wav to find out about many basic attributes of a class. A 

30 description of these basic attributes is given in Table 1 below. 



Table 1 

Multi-thread-safe An insrance of this ciass can be concurrentiv accessed bv 

more than one thread - 

-Muhi-insiance-sare Mulripie instances of this surrogate ciass can be 

concurrently used to access the real obiect. 

Static-sate It is OK to construct an instance of this ciass at static 

construcnon nme. 
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bnarca-memorv-sare 

Si-Trocare ' V'alue 

Allows -.ruicntance 

Allocation 

Abstract /Concrete 
ScoDe or uruaucness 



It IS OK to keep an instance or this ciass in shared- 
menx)r\' 

Describes whether an instance or this ciass is a 
surrogate tor some o:ner object. 

An instance or this ciass can be subclassed. 5ome classes 
are designed to De used nnonomorphicaliy. 

Describes whether this ciass allows creation ot 
instances on the stack or heap or both. 

Describes whether this ciass allows creanon of obiects- 

Provided onlv tor idennrner classes, it dermes the name- 
space withm wnicn the laentifier is uruaue. 



Incidental system functions like assignment operator, copv constructor, 
and streaming operators. 

20 The messaging system needs to keep messages m some storage 

device (e.g., a magnetic or optical disk drive, a RAM, or a floppy disk). 
message bin classes provide abstractions ror different kinds of message 
storage. A message is always associated with a message bm. FIG. 9 is a 
block diagram of the class hierarchy for the preferred embodiment 

25 message bin classes. 

The root of the hierarchy is an abstract mixin class, message bin 
class 700, which represents a message bin of any kmd. An example of 
this class is implemented in the preferred embodiment as the 
MMessageBin ciass 700 and could be implemented in anv other generic 

30 message bin class. There are two main kinds of bins. First, there are 

bins that allow storing messages into them.. Second, there are bins that 
allow retrieving messages from them. The rormer is represented by the 
message store mixm class 702 and the latter is represented bv the 
message source mixin class 704. An example of these classes are 

35 implemented m the preferred embodiment as the MMessageStore class 
702 and xVIMessageSource class 704. Each of these could be implemented 
in any other generic message store class and message source class, 
respectively. Concrete subclasses that allow both storage and retrieval of 
messages will inherit from both mixins. The preferred embodiment 

40 messaging system provides such concrete classes. 

The message sender class provides the functionalitv for message 
submission and sending. An example of this class is implemented in 
the preferred embodiment as the MMessageSender ciass 706 and could 
be implemented in any other generic message sender ciass. A sender 

45 always needs a store to keep the submitted messages. In the preferred 
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embodiment. to simpiify client application's usage, a MMessageSerider 
706 IS a MMessageStore 702 as well. Similariv, receiver functionality is 
provided bv message receiver class 708 for receiving messages at a 
receiver-address. An example of this class is implemented in the 
preferred embodiment as the MMessageReceiver class 708 and could be 
implemented in any other generic message receiver class. It also is a 
MMessageSource 704 so that client applications can retrieve messages 
directly from it. 

The MMessageBin class 700 is the root of the bm class hierarchy. 
It defines a protocol that all bin classes must support as noted in Table 2 
beiow. 



Basic Attributes: 



Table 2 



15 



20 



30 



Mufti-thread-safe 


Ye? 


Surroeate /Vaiue-I ike 


Surroeate 


Muhi-msrance-sare 


Yes 


Allows inheritance 


Yes 


Sranc-sare 


jVo 


Allocation - stack. heao 


Hear 


Shared -memorv-sa re 


N'o 


Abstract /'Concrete 


Abstract 



Jnhents From: 

VlReferenceCounted 

Constants. Enumerators. Types: 

• enum 

EStatus (kAvailable. kLinavailablel 

MemDcr Funcnons: 

• \ irrual EStatus 
GetStatu-- {) = 0 

• \-irruai boo! 

Contains tconst TMessageReterencecj; messaee; 

• \ irruai bool 
DeleteAil () = 0 

• virruai TCountedPomterTo<TMessageBin]NJame> 
GetiName 0=0 



The enumerator Estatus reflects the status of a bm. In particular a 
bm may be currently unavailable (e.g., the network connection mav be 
broken). A message bin will attempt reconnection upon a function-call 
if it IS unavailable. One status is "kAvailable" which means that a 
message bin is currently accessible. Another status is "kUnavailable" 
which means that a message bin is currentlv inaccessible. 

The GetStatus runction returns the status of this bin. If the 
returned value is kUnavailable, the bin is currently maccessible. If the 
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bin IS unavailable and trvReconnectlfUnavaiiable is true, this call wiii 
artempr reconnection before returning the status. 

The Contains function returns a true value, if the specified 
message itself is contained within the storage represented bv the bin. 
5 Tne DeleteAll function deletes ail messages in this bin. After 

successful completion, this function will leave the bin empty. A 
successful completion is indicated by the returned value of true. This 
Function will not delete a message that is currently bemg accessed. In 
that case, it returns a false value after deleting all other messages. 
10 The GetName function returns the message bin name for this 

bin. 

The MMessageSource class 704 is a subclass of MMessageBm 700 
that adds message retrieval protocol as noted in Table 3 below^ 



5dS!-: Atmbutes: 


Table T 


Mu!:i-thread-sate 


Yes 


5u r roea te / V a 1 u e- i i k e 


Surrocate 


\!uln-instance-sar'e 


Yes 


Allows inheritance 


Yes 


Stanc-sare 


No 


Allocation - stack. heao 


Heao 


Sha r£>d - memorv-sa te 


Mo 


Abstract /Concrete 


Abstract 



Irihents From: 
M MessageBin 



Member Funcnons: 

• v irtual TMessaeeReference 

GetAUMessaces (TCoilecrionOf<TMessaeeReference> 6^ 
rerumed Messages I const = 0 

25 • \ irruai unsigned lone 

GetMessaeeCount( \ const=G 

• \irtijal T Message Reference 

VVaitForMessageAtter (const TMessageReference<ic startincPomt) = 0 

• virtual TOniyPointerTo<TMessagelterator> 
30 Createiterator () const 

The GetAllMessages function adds the message references of all 
the messages in this bin to the supplied collection. Previous contents of 
the collection are left unchanged. 
35 The GetMessageCount function returns the number of messages 

contained in this bin. 

The WaitForMessageAfter function blocks the calling thread 
until this bin has a message whose LocalCreateTime is later than the 
LocalCreateTime of startingPoint. If an invalid TMessageReference is 
40 passed then the starting LocalCreateTime is assumed to be 
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'70^ 

TTime::kNeganveInrinity, and the nrst message in the bin will be 
returned. 

The Createlterator creates an instance of the message iterator class 
710 to Iterate over the messages m this bm. An example or this class is 
implemented m the preferred embodiment as the TMessagelterator 
class 710 and could be implemented in anv other generic message 
Iterator class. 

The TMessagelterator class 710 provides iteration functionality 
over a collection of messages, pnmariiv a message source as noted m 
Table 4 below. 



15 



20 



Basic Attributes: 



Table 4 



Inherits From: 
None 

Member Functions; 

• virtual TMessageReference 
First ( ) = 0 

• v irtual TMessageReference 
Next 0=0 

v irtual rNlessageReterence 
GetMosiRecent () const = 0 



Muhi-thread-sare 


No 


Surrogate/ Value-iike 


\'aiue-iike 


.Vluiti-insrance-sar'e 


^es 


Allows mheruance 


\es 


Static-sare 


No 


Allocation - stack. heap 


Heap 


Shared -memorv-sare 


No 


Abstract /Concrete 


Abstract 



30 



35 



The First function returns the first message in this bin. If the bin 
IS empty, an invalid TMessageReference object is returned. 

The Next function returns the next message in this bm. If the bin 
is empty, an invalid TMessageReference object is returned. 

The GetMostRecent function returns the most recent 
T]V4essageReference returned by either the First or Next function. If the 
bin is empty or no calls to First or Next function have been made, an 
invalid TMessageReference object is returned. 

The MMessageReceiver class 708 is a subclass of MMessageSource 
class 704 that can receive messages and adds protocols to get its address 
as noted in Table 5 below. 
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Tabie I 



Basic Atmbutes 



Mult: - threa d -sa re 


Yes 


TiUT roea te / V a i ue- ) i k e 


Surroeatc 


Vt u ! t ! - 1 n s t a nce-sa re 


Yes 


Allows inheruance 


Yes 


Stanc-safe 


No 


Allocation - stack. heao 


Heao 


5ha red-memor\- - sa re 




Abstract / Concrete 


Abstract 



Inhents From: 

MMessaccSource 

Member Funcnons: 

• virtual TCuuntedPomterTo<TMe>sa^eRcceiver Address> 
GetiXame • ) = 0 



The GetAddress function returns the address for this receiver. It 
may be used to send messages to this receiver. 

The MMessageStore class 702 is a subclass of MMessageBin class 
700 and adds message storing protocol as-noted in Table 6 below. 



20 



Basic Attributes 



Table 6 



Multt-rhread-sare 


Yes 


Surrogate /Vaiue-iike 


Surrocate 


VI ulti-insta nce-sa te 


Yes 


-Allows inheritance 


Yes 


Static-safe 


Mo 


Allocation - stack. heao 


Heao 


Shared -memorv-sa re 


No 


Abstract/Concrete 


Abstract 



inherits From: 
MMessageBin 

Member Functions: 

• virruai TMessaeeReferenco 

Copyinro i const TMessaeeKet'erence^i: messageReterence. 
booi allow Duplicates = talsej 



30 



The Copylnto function copies the specified message into this bin. 
If the message is contained in this bin, another copv is made if 
allowDupiicates is true, h returns a reference to the new message. If the 
message is contained m this bin and allowDupiicates is false, then an 
invalid reference is returned. 

The MMessageSender class 706 is a subclass of MMessageStore 
class 702 and adds protocol for sending messages as noted in Table 7 
below. 
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Basic Atrribu res • 



Muiti-threaci -sa re 



Muiti-insrance-sa re 



btatic-sare 



bhared-memo r\' - sa ie 



-22- 
Table 7 



Ves 



Ye? 



^urrocate/Vaiue-iikP 



Allows inheritance 



Allocanon - stack. hear 



N'"> I Abstract /Concretp 



inhents From: 

MMessageStore 

Member Functions: 

• virnja! TMessaceReference 

Suomir (const TDranMessaeetc messages = 0 

♦ static TCountedPointerTo<MMessa^e5ender> 
GetDetauJtSender () = 0 



Surrogate 



Yes 



15 



20 



30 



The Submit runction submits a message m draft state tor deHve^^' 
^us recipients. After this call, the message is no longer a draft message 
The draft message, passed in as a parameter, is invalidated and a 
message rererence object instantiated from a message reference class 71-> 
wnich points to the submitted message is returned. An example of this 
class is implemented in the preferred embodiment as the 
TMessageReference class 712 and could be implemented m anv other 
generic message reference class. 

The GetDefauitSender function returns the default 
MiMessageSender. It is primaniv used to submit messages. 

Tne fUe svstem message store class 714 is a concrete subclass or 
MMessageSender class 706 (which ,s a subclass of MMessageStore class 
/02) ana a subclass of MMessageSource class 704. It represents a fiie- 
svstem-based message bm. Messages are stored in a file svstem directorv 
It provides tunctionalitv for storing, accessing and sending messages as 
noted ,n Table 8 below. An example of this class is implemented in the 
preferred embodiment as the TFileSystemMessageStore class 714 and 
could be implemented m any other generic file svstem message store 
class. ■ ° 
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Basic A-rr'.butes: 



InhenCB From: 

VlMessageSender 
MMessageSource 

Member Functions: 
1 TDirectorv 

GetDirectory (1 cons: 
I booi 

DeleleSelf {) 
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Table S 



Multi-thread-sare 


Yes 


5 u rroea te / V a 1 u e- i ike 


Surrocate 


Multi-insrance-sare 


Ye? 


Allows inheritance 


Yes 


Static-sare 


No 


Allocation - stack. hear 


Hean 


Sha red - memorv-sa fe 


No 


Abstract /Concrete 


Concrete 



15 



20 



Tne GetDirectorv function returns the directory used for message 
storage, 
boo! 

The DeleteSelf function deletes all messages m this bm and, if 
successruL deletes the bin itself. A successful completion is indicated bv 
the returned value of true. This function will not delete a message that 
is currently being accessed — in that case it returns false after deleting 
all other messages and the bin remains intact. If successful, subsequent 
calls to GetStatus will return kUnavailable — all other calls will result 
m a TlVlessageBinUnavailable exception being thrown. 

Accessing a specific instance of a message bin requires that the 
client be abie to specifv- that bin. This is accomplished using a bin name. 
Once a bin name is obtained or constructed, a bin can be obtained usm<^ 
the bin name. Bin names are also used to address messages. 

The message bin name class 716 and all subclasses, shown in FIG. 
10, must be displayable every^vhere. An example of this class is 
implemented in the preferred embodiment as the TMessageBinName 
class 716 and could be implemented in any other generic message bin 
name class. The protocol for display name is handled bv the base class. 
In addition, they must be transportable everyw^here. The default storage 
and streaming behavior is managed by the base class to ensure that 
slicing never occurs. 

An instance of the TMessageBinName class 716 identifies a 
message bin. hs primary purpose is to allow a client to access a message 
bin. A TMessageBinName class 716 supports the GetPresentationName 
and GetTextPresentation functions. The TMessageBinName class 716 
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does not slice so that all of the data of the ongmai class as well as the 
type is preserved as noted in Table 9 beiow. 



Basic Attributes: 



Table 9 



10 



15 



20 



Multi-thread-safe 


Yes 


Surroeate/ Value- like 


Value-hke 


Muiti-instance-satc 


n / a 


Aliows inheritance 


Yes 


Static-sate 


.Vo 


Aliocanon - stack. heao 


Heao 


Shared-rp.emorv-safe 


No 


Abstract /Concrete 


Concrete 






Scooe ot uruaueness 


Gioba! 



Inhents From: 

N-O^eterenceCoun ted 

Member Functions: 

• TCDuntedPomterTo<MMessageBtn> 
GetBin () const 

• \-oid 

GetPresentanonName iTTextiit hilir.i const 

• \ Old 

GetTextRepresentation (TTextii: tillm5v Appendinc: f const 

The GetBin runction returns a counted pointer to the message 
bin. If the TMessageBinName class 716 is invalid, or the class library tor 
the specified bin is not available, an exception is thrown. 

The GetPresentationName function returns the presentation 
name ot the message bm. The presentation name is that which would 
be used when displaying the name of the bin to the user. 

The GetTextRepresentation function returns a text representation 
of the message bm name. Many message bins have a valid text 
representation for the bm name. This text representation is usually 
sufficient to fully specifv the bin. 

An instance of the file system message store name class 714 
identifies a file system message store as noted in Table 10 below. An 
example of this class is implemented in the preferred embodiment as 
the TFileSystemMessageStoreName class 714 and could be 
implemented in any other generic file system message store name class. 
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Table 10 



Niulti- thread -safe 


Ye? 


5urrocare/ Vaiue-iikc 


Value-hke 


M ul:i-instance-sare 


n / a 


Allows inheritance 


Yes 


Stanc-sare 


No 


Allocation - stack. hean 


Heap 


Shared -memorv-sare 


\*o 


Abstract /Concrete 


Concrete 






Scot?e or uniaueness 


Global 



Inhents From.: 

TVlessageBinName 

ember Functions: 
TrileSvstemMessaceStoreXame (const TDirectorv<ic directorvj 

TCountedPointerTD<TFile5ysterruVlessat:eStore> 
vjetStore ( ) const 

• TDirectorv 

GetDirectorv (j const 



30 



The TFileSvstemMessageStoreName runction constructs a file 
<vstem message store over a directorv. This cali throws an exception if 
the directorv is invalid. 

The GetStore function returns a counted pointer to a file system 

store. 

The GetDirectory function returns a directory used for messages 

storage. 

An instance of the TMessageReceiverAddress (also known as 
MessageReceiverAddress) class 718 identifies a message receiver. Its 
pnmarv purpose is to allow a client to access a message receiver and for 
constructing a message address bundles 720 rrom its class tor sending 
messages as noted in Table 11 below. .An example of this class is 
implemented in the preferred embodiment as the 

TMessageAddressBundle class 720 and could be implemented in anv 
other generic message address bundle ciass. 
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Basic Attributes- 


Tabip n 


Multi-rhread-sare 


Yes 


Surrocate/Vai'ji?-]ike 


Value-like 


MuJn-mstance-sare 


n / a 


! Allows mherirancc 


Yes 


5tatic-safe 


N'o 


Allocation - stack heao 


HeaD 


5ha red - memorv-sa re 


No 


Abstract/Concrete 


Concrete 






ScoDe of uniaueness 


Global 



inhents From; 

TMessaceBiru\ame 

Member Functions: 

• virtual TCountedPornterTo<MMessageReceiver> 
CjetMessageReceiver i ) const 

The Get.MessageReceiver function returns a counted pointer to a 
message receiver. It throws an exception, if the receiver carrot be 
constructed, or if an instance of TMessageRecei verAddress class 718 i. 
invalid. 

Particular service provider classes can be subclassed rrom anv of 
tnese previouslv described classes to further enhance the tunctionaiitv 
ot tne messaging interface 400. For example, a Internet receiver address 
class 722 can be generated by inheriting functionalitv from the 
TMessageRece.verAddress class 718 to add Internet addressing 
capabilities. An example of this class is implemented in the oreferred 
emood.ment as the TInternetReceiverAddress class 722 and could be 
implemented in anv other generic internet receiver address class 
bimilarlv. classes can be generated for other messaging systems such as 
A .400. 

An instance of the TInternetReceiverAddress class 722 identifies 
an RFC-S22 compliant mailbox address as noted in Table 12 below. 
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Table 12 



Inhencs From: 

TMessaee Receiver Ad dress 



Mulii-thread-sare 


No 


iurrocate/ Vaiue-hke 


Value-iike 


VIu!ti-!nsrance-sare 


n / a 


Allows inheritance 


Yes 


Static-sare 


No 


Aliocarion - stack. hear 


Heap 


Sha red - memo rv-sa re 


No 


Abstract /Concrete 


Concrete 






ScoDe or uniauenes«i 


Global 



-Member Fujicnons; 

TintemeiReceiverAddress (const TText<S^ RFC -S22ad dress) 

Tinterr^tRece.verAddress (const TText^ userName. const TText<St 
nosLName. const TTexto: oresentanon^Name = 
! brandard i ext:;GetEmprvText()) 

• void 

GetParts uTexti localPart.TTe.x:^: domainParn const 

The TInternetReceiverAddress function constructs a 
TInternetReceiverAddress from an RFC-822 conformant strmg. This 
'.vill throw an exception, if the passed string is not a valid RFC-S22 

address. 

The TInternetReceiverAddress function constructs an Internet 
address rrom components that can be used to form a RFC-822 
conformant string. 

The GetParts function returns local and domain parts of the RFC- 
S22 address. For a more detailed discussion of the Internet messacm- 
standard and the svnta.x ot an RPC-S22 Internet address, see Reque"st For 
Comments 822 (RFC-822) by Dave Crocker dated August 13. 1982. 

A message class 724 represents a message. An e.xample of this 
class IS implemented in the preferred embodiment as the TMessage 
class 724 and could be implemented in any other generic message dass 
There are manv kinds of messages in a messagmg svstem. For example 
some kmds are messages received at an address, messages sent from an 
address, and messages in construction yet to be sent. 

Various subclasses of the TMessage class 724 represent different 
kmds ot messages as shown m FIG. 11. The TMessage class 724 has the 
basic functionality for all of them as noted in Table 13. 
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Table 13 



inhenrs From: 
None 



\!u:ti-*hread-sare 


Xo 


Surroeate/ Value- like 


V'aiue-iikt' 


Muit'-msrance-sare 


n / a 


Allows inheritance 


Yes 


5tatic-sare 


No 


Allocation - stack. heap 


Heap 


Shared-memorv-sare 


No 


Abstract /Concrete 


Concrete 



Constants. Enumerators. Tv-pes: 
Componentlndex kJnvalidLndex 
An in\ ahd Componentlndex. 
tnum 

EStanjs ikDrart. kPendxng, kSendinq, 
kSent, kKeceived. kFaiiedj 

enum 

Eimportance ikBulk. kNormai. klmportantj 
enum 

EStTeamformat (kVionomorphjc. kPolvVlorphicI 

lemoer Funcnons; 
boo! 

IsValid ( ) const 
cool 

operator=:= tconst TMessage&c messagej const 
booi 

operaror!= (const TVIessagecic message) const 
booi 

operator > < const TMessage<i: messagej const 
booi 

operator < tconst TMessage<i: messaget const 
boo! 

operator (const TMessagetii m.essagej const 
booi 

operator <= (const T\tessage&: messaeej const 

HashResuit 

Hash t J const 

booi 

IsConrainedin (const MMessageBin& m.essageBm) const 
unsipied lonp 

CountAddresses (TMessageAddressBundle::Kjnd5et filter) const 

Componentlndex 

CountComponents () const 

Componentlndex 

DoesContainType i const TTv-pc5urrogateit component T\T?e) const 
boo} 

IsConriponentTv'pe (const TTv-peSurrogateiit componentTvpe, 
Componentlndex index) const 

void 

GetComponentTvpe (TType5urTogate&: fillm. 

Componentlndex maexi const 
ESrrea mrorma t 

GetComponentStreamFormat (CompKjnendndex index) const 
void 

GetSubiect (TTextAt fillin) const 
EStatus 

GetStatus () const 
Elmportance 
Getlmportance () const 
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• TTimo 

. GetCrea leTi me O const 

• TTLme 
GetLocaiCreareTime 1 1 const 

T Counted Pointer I o<M\tessaf:L»Bin> 
CetBm ' * const 

• void 
DeleteSelt () const 



-^0 The EStatus enumerator reflects the status of a message. The 

message may have a status of manv different types. For example, 
"kDraft" means that an mstance of the TMessage class 724 has not vet 
been submitted for delivery. All newiv created messages are m this state 
and remam in this state until the client application calls Submit or Send 

15 on It. .Another status is "kPendmg" which means that an instance of 
the TMessage ciass 724 was submitted by the client application for 
delivery but the messagmg system has not vet sent it to a messae:mg 
server. Another status is "kSending" which means that an instance of 
the T\4essage class 724 is currently bemg sent to a messaging server. 

20 Another status is "kSent" which means that an instance of the 

TMessage class 724 was successfully sent to a messaging server. Another 
status is "kReceived" which means that an instance of the TMessage 
ciass 724 was received by the messaging system. Another status is 
"kPailed" which means that an instance of the TMessage class 724 could 

25 not be delivered. 

The Elmportance enumerator has many values, including: 
"kBulk". "kNormal", and "kmportant". Each is an indication of the 
client application's assessment of the importance of this message. 
"kBulk" is the least important and "kimportant" is the most. This tag 

30 (enumerator) is mutually interpreted by the messaging client 

applications, because it is not interpreted by the messaging system. 

The EStreamFormat enumerator preferably has two values. One 
value is "kMonomorphic", which indicates that an instance of the 
TMessage class 724 was added using the AppendMonomorphic 

35 runction, and must be retrieved using GetMonomorpic function. 

Another value is "kPolymorphic", which indicates that an instance of 
the TMessage ciass 724 was added using the AppendPolvmorphic 
function, and must be retrieved using the GetPolymorphic function. 

The IsVahd function checks if an instance of this class is a valid 

40 message. A message created using an empty constructor and a message 
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rererence returned at the end of an iteration are invalid rererences It 
returns a true, if the message is valid. Most operations on an mvaUd 
.. message wul fail. Operations on a valid rererence might still fail if the 

message nas been deleted or otherwise unavailable for access 
' . operator== and operator!^ functions check for equahtv and 

inequahtv. respectiveiv. between two messages. The first returns a true 
and the second returns a false, respectiveiv. onlv if both references refer 
to the same message. The other operator runctions perform an ordered 
comparison check for two messages. Message order is based on the 
10 LocaiCreateTime. 

The Hash function returns a hash kev for this message. 
The IsContamedin function returns a true if this message is from 
the storage represented by messageBin. 

The CountAddress function returns .the number of address in 
i:) tnis message whose kind matches filter. 

The CountComponents function returns the number of 
components in this message. The DoesContainType function 
returns the index of the first component of type described by 
componentType. It returns kinvaldlndex, if no matchmg t^^^e ,s found 
The IsComponentType function returns a true if the component at 
specified index is of type described by componentType. The 
GetComponentType function returns the type of component at specified 
index m fill.n. The GetComponentStreamFormat function returns the 
streaming format for component at specified index in filUn. 

The GetSubject function assigns the subject for this message to 
tilhn. The GetStatus function returns the status of this message The 
Getlmportance function returns the importance tag for this message. 
The GetCreateTime function returns the time in UTC (Universal 
Coordinated Time) when this message was created. The 
GetLocalCreateTime function returns the time in UTC (Universal 
Coordinated Time) when this message was created in the current bm 
Will create time unless this message was copied from another bin 
(see MMessageStore::Copyinto) in which case it is guaranteed to be > = 
create time. The GetBin function returns a counted pointer to the 
message bin that contains this message. 

The DeleteSelf function deletes the message referenced bv this 
object. The DeleteSelf function may fail if the message is a draft 



20 



30 



SUBSTITUTE SHEET (RULE 26) 

NJSDOCID; <WO 9722928A1_I_> 



wo 97/22928 



rCT/US96/20536 



-31- 

message and is currentiv being accessed. Failure tvpicallv is indicated b\' 
an exception. 

The TMessageReference class 712 is a subclass or the TMessage 
class 724. It represents either a received or submitted message. A 
message of this kind can not be modified as noted m Table 14 below. 



Basic Attributes: 



Table 14 



10 



15 



20 



-ID 



inhents From: 
TMessage 

Constants. Enumerators^. Tvpes: 

Hintecnrv' Iklntact. kDoNotKnowt 

-Member FuncnofLS: 

• TTime 
GetSubmitTLine O const 

• TTime 
GetReceiveTime {) const 

• Elntegnrv- 
Getlntegnn' () const 

• TSTream^ 

operator>>= (TStreamiic toWherei const 

• T5Tream6c 

operator<<= (TSrreamti: from Where) 



.Multi- thread-safe 


No 


Surrocate/ Value- like 


SuTToeate 


Muiti-instance-safe 


Yes 


.Allows inheruance 


Yes 


Stanc-sare 


N*o 


AHocatJon - stack-hear? 


Bith 


Shared -memorv'saie 


N'o 


Abstract /'Concrete 


Concrete 



40 



The enumerator Elntegnty can have a "kintact" value, which 
means that an mstance of the TMessage class 724 was received without 
any loss of data. Alternatively, a "kDoNotKnow" status means that an 
mstance of the TMessage class 724 does not have enough information to 
judge Its mtegrity. 

The GetSubmitTime function returns the time in UTC 
(Universal Coordinated Time) when this message was submitted for 
delivery. The GetReceiveTime function returns the time m UTC when 
this message was received. If the message status is not Kreived, then 
the message has never been received (probably because it is an outgoing 
message) and the time returned is TTime::kPositiveInfinitv. 

The Getlntegrity function returns the integritv with which this 
message was received. 
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The opera,or»= and op.r=,ar«= f.nCons streams ,h,s 

TnolT ™' "^"^'^ - «spec.,veK., a 

The TMessage class 724 ,s generally useful for referring ,„ anv 
. k.nd o, a message and access.ng ,he message data. It does no' Irov.de a 
protocol tor the creat.on and add.t.on of data, because not all m ss Is 
support that behavior. For e.vample, recened messa„. 
nte draft message Cass ... and ,t's suhCassL pTo:: I 
constrttcnng a new message, vvr.t.ng data to ,t and sendmg , ^ 
0 example o, this class ,s implemented in the Dreferred embodimT , 
the TDraftMessage class and could he tmplemenL n^ ,": f 
generic draft message class. ' 

throueh aT'"'' " OOP-based messaging system mav travel 

through a sertes o, messaging routers (most of which will be non-OOP- 
based tor ,u,te some time,, recipient for the message mav be a n^^ 
OOP-based messaging svstem. h, such an environment, the issues of 

non o'op°r "° -'"ope^abiHtv w„h 

non-OOT-basea systems needs to be clearly defined. Several subclasses 
o the TDraftMessage class 726 may be defmed to support different rad=- 
offs between data-integrity and interoperabiUtv "ent trade 

For example, the OOP-specific message dass 728 guarantees the 
data integntv when delivered to a recipient. exampt of this clasl is 
implemented in the preferred embodiment as the 
TCommonPomtMessage class 728 and could be implemented ,„ an^ 

svstLT"" T"'' 00''--sed messagmg 

system fe.g., a CommonPoint'" messagmg svstem) will be able to 
retrieve the data from an instance of the TCommonPomtMessage class 
-^28. CommonPoint-. .s a trademark o( Taligent, Inc. In contrast, the 

non OoTk T"^" ™ " '"'^^-'^W- by and can be sent to a 

non-OOP-based messaging system. „, however, does not guarantee data 
tntegntv. m particular, an instance of the interoperable message Cass 
730 mav have undergone lossy transformation of message contents An 

ZT. V " *e preferred embodiment as 

the TlnterOperableMessage class 730 and could be implemented in anv 
other generic interoperable message class. 

A CommonPointT" messaging system client at,plica,ion will 
choose a kind of draft message based on the requirements for data 
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intcgnty and interoperability dictated by the problem domain as noted • 
in Table 15. 



Table 15 

0 Basic Attributes- 



M u 1 ri - th read -sa * e 


No 


Surroeate /\'3;ue-iike 


Surroeate 


Multi-mstance-safe 


Yes 


Allows inheritance 


Yes 


Sta he-safe 


No 


Allocation - stack. heap 


Both 


Shared -memorv-sa re 


No 


Abstract /Concrete 


Abstract 



inhents From: 

TMessageReference 



10 Constants, Enumerators, T\'pes: 

• enum 
EReplvReciDieniHandling 

IkReplyToSenderOniy.kReplvToAllReciDients) 

• enum 

' - ECopvRccipientHandiine ikCopvNoRccipients.kCoovAilReciDientS! 

• tSTum 

ESub:ec:Handiinp I kDoNotCopySubicct. kCopvSubiectt 

• OTum 

' HComponentHandbng IkCopyN'oComponents. kCopyAlIComponentsl 

Member runcnons: 

• void 

Append Address (const TMessageAddressBundle^ bundlel 

• \-oid 

~ AppendAddress tconst TCountedPointerTo<TMessaceReceiverAddress><v 

address. TMessageAddressBundie::EKind = T.^essageAddressBundle:;kTo) 

• void 

AppcndCom.ponent (const T7^1essageReterence6c rromWhere, 
Componentindex index) 

30 

The following enumerators control message creation behavior, 
when a draft m.essage is created as a reply, forward, or copv or an existmt: 
message. 

The enumerator EReplyRecipientHandling controls recipient 
35 handling when creatmg a draft message as a reply o a message. It mav 
have a "kRepiyToSenderOnly " value which uses the sender of the 
original message as a recipient. Alternatively, it mav have a 
"kReplyToAlIRecipients" value which uses all of the recipients of the 
original message as recipients. 
•10 enumerator ECopyRecipientHandlmg controls recipient 

handling w^hen creating a draft message as a copy of a messac^e. It may 
have a "kCopyNoRecipients" value which does not copv anv recipients 
rrom the existing message. Alternatively, it may have a 
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-■kCopvA]lRec.p:ents" value wh.ch cop.es ai! reop.ents from the 

existing message. 

The enun,era.cr ESubjecHandhng controls ,he subjec, handling 
_ u hen creanng a dra„ n,essase as a fonvard. reply or copv of a n^essase 
. . n,av have a -.OoNo.Cop.vSuhiec.- .-h.eh ,„d,ca.es .ha. .he Tu^ o. 
.he or,Bmal message is no. ,o be copied ,o ,h,s message. Al.ema. velv 
may have a .CopySubjec.- value wh.ch .nd.ca.es .ha, .he subjec. oi 
.he ongmal message may be copied .o this message 

hand/"' EComponentHandhns controls .he componen. 

handlmg >vnen creafng a draft message as a forward, replv or copv of a 
tnessage. 1. mav have a "kCopyNoComponen.s- value wh.ch .ndica.es 
na, none o, .he componen.s of .he ong-nal message are to be copied to 
eh.s message. .^Itemattvely, .. may have a ■■kCopvAllComponen.s- 
value u-h.ch .nd.ca.es .ha. .he componen.s of .he or.gmal message mav 
be copiea to this message. ^ 

""^.^ Append AddressBundle adds an address bundle to 

the hst or addresses tor th.s draft message. It may also add an address 
bundle wth the specified address and kmd to the hst or addresses for 

this draft message. 

The runction AppendComponent cop.es component at mdex m 
message tromWhere to next mdex m th.s message and returns an 
acdress to the list of addresses for this draft message. 

The TCommonPointMessage class 728 ,s a concrete subclass of 
TDratt.Message class 726. TT..S message supports multiple components 
or anv data-tvpe and styled-text as subject, h does not t;ansiate the data 
from Its original form to any other as noted m Table 16. 
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Table 16 



3asic Attributes: 



Multi-threiid-sare 




5urrocatc / Value-like 


Surrocare 


Muiti-:nstance-sare 


Yes 


Allows inheritance 


Yes 


Sratic-sare 




Allocation - stack. heao 


Both 


5hared-memorv-sare 


No 


Abstract /Concrete 


Concrete 



inhents From: 

TDrattMessage 



Member runcnons; 

TCommonPomtMes5age iconst TTextSc subject i 

10 TComrnonPointMessace (const TTextic subject, const 

TCountedPointerTo<TMessaeeReceiverAddress>6: to Address) 

• static TCommonX^ointMessage 

Forward (coast TVlessaeeReference<&c sourceMessa^e, 
1 - EComponent Hand line componentHandiinc;. ESubiectHandUng 

subjectHandlmg, const TTextcij: DrependToSubiect = 
T5landardText::GetEmprv-TextO) 

• static TConnmonPo:nt Message 

^ Kepiv tconst TMessaeeReference&: sourceMessa^c, 

ERepiyRecipientHandiLne rec:pien:Handiing, 
EComponent Handling com ponent H and hnc.ESubiectH and ling 
subiectHan^iinE;- const TTextAc preDendToBubtect ~ 
TS:andardText::GetEmpr\'TextO) 
^ • stanc TConnmonPomtMessage 

^opy (const TMessace<ic sourceMessage, ECopvRecipientHandting 
reapientHandUng. EComponentHandiing componentH and lint;, 
E5uDiectHandiing subiectHandlinc, const TText<i: 
prependToSubiect = TStanaardText::GetEmDtvText()) 



30 The r'unction TCommonPointMessage allows client applications 

to create new CommonPomt"^'^' messages with a specified subject. One 
oi the constructors allows specifvmg an address to which this message 
should be sent. 

The function Forward creates a Com.monPomt"^^' message as a 
35 forward of the specified message. The newly created CommonPoint'^'^^ 
message is properly formatted as a forwarded message. Parameters 
componentHandling and subjectHandling provide clients a fmer 
control of controlling various properties of the created message as 
described earlier. If prependToSubject is present, the specified text is 
40 prepended to the subject of sourceMessage to create subject for the 
returned message. 

The function Reply creates a simple message as a repiv to the 
specified message. Tne newly created simple message is properlv 
formatted as a reply message. Parameters are handled m manner 
45 similar to Forward function. 
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The runctmn Copv creates a sinnpie message as a conv of the 
.penned n^.essage. Parameters are handled m manr^er s.miiar to 
Forward function. 

The TInterOperableMessage class 730 ,s a concrete suociass or the 
TDrattMessage class 724. Pn. message supports mult:ole components 
or any data-type and unstvied-text as sub,ec.. Upon transm.ss.on :t mav 
translate the data from .ts ongmal form to one appropriate tor passage ' 
tnrough the messagmg svstem. Such a translation mav mcur loss or 
information rrom the data as noted in Table 17 below.' 

Table 17 



Basic Atrributes: 






Multi-thread-safe 


No 


Surroeate/Vaiue-iikp 


Surroeare 


.ViuJtj-msrance-sare 


Yes 


Allows inheritance 


Yes 


Static-safe 


No 


Allocatjon - stack. heao 


Both 


5ha red-memor\'-safe 


No 


Abstract /Concrerf> 





inherits From: 

TDraftMessage 

VIember Functions: 

TInterOperableMessage (const TTextfic subject) 

TInterOperableMessage (const TText^ subiect. const 

TCountedPointerTo<TMessageReceiverAddress>^^toAddress) 
TInterOperableMessage (const TText& sub,ect. const 

TCountedPomterTo<TMessa^eReceiverAddress> . 
ibtanaardTexti^ nrstComponenti 



toAddress. cons: 



• static TinterOperabieMessage 

Forward iconst TMessaceReference^i. sourceMessace 

LLomDoneritHandiing componentHandlmc £-ub,ectHnnHl,nn 
sub,ectHardimg const FText^c preoendToSut,^ . 
TStanaardText::GetEmptvText()) ' 

• static TInterOperableMessage 

Replv (const TMessageReference& sourceMessace 
tKeplvRecipientHandimg recioientHandhnc 
hLomponentHandling componentHandlmp "ESubiectHanHhr^o 
sub,ectHandimg const TText& prependToSu^^t^^^"*^^ 
TStandardText::GetEmptvText()) "^^it^i 

• static TInterOperableMessage 

Copy (const TMessaee<k sourceMessaee. ERecipientHandimc 

prependToSubiect = TStandardText::GetEmptyText()) 

The function TInterOperableMessage allow cHent appHcat.ons to 
create new mteroperable messages with specified subject. One of the 
constructors allows specifymg an address to which this message should 
be sent. Another constructor supports the (monomorph.c) addition of a 
smgle text component. Regardless of which constructor is used so that 
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ciient appiications can add additional components using the 
AppendMonomorphic and AppendPolymorphic functions. 

The function forward creates a CommonPointTN" message as a 
forward of the specified message (sourceMessage). The newlv created 
CommonPointTM message is properly formatted as a forwarded 
message. Parameters componentHandling and subjectHandling 
provide client applications a finer control of controlling various 
properties of the created message as described earlier. If 
prependToSubiect is present, the specified te.xt is prepended to the 
subject or sourceMessage to create subject for the returned message. 

Tne function Reply creates a simple message as a reply to the 
specified message. The newly created simple message is properly 
formatted as a reply message. Parameters are handled in manner 
similar to Forward function. 
^-"^ "i^^e runcnon Copy creates a simple message as a copv of the 

specified message. Parameters are handled in manner similar to 
Forward function. 

A com.ponent inside a TDraftMessage class 726 can be any 
CommonPomti"^' object. Functionality of writing a component to a 
message and reading one from it is provided in a type-safe way by 
template functions Add and Get. Conceptualiv. the components in a 
message form an indexed collection. Client appiications can add 
components to a message sequentiallv and access a component using an 
mde.v. Some of these functions are detailed m Table 18 below. 

Table IS 

F Linen ons: 

• tempiate <ciass AT\'pe> Componentlndex 
Append Pol v-morphic rTDrattMessage<i: message, const ATv-pe^t component ) 

• tempiate <clas5 ATv'pc> Componentlndex 

Append Monomorpnic (TDraftMessageiic message, const ATv-pe&c component) 
temolate <ciass AT\-pe> void 

GetPolvmorphic ico^xst TMessage& message. TOnlvPomterTo<ATv'pe>6. 

nUin. v^omponentLndex indexj 
35 • template <class ATv'pe> void 

GetMonomorphic (const TMessage<i: message. AJ\roe6z fillin. 

Componentlndex index) 
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The function AddPolymorphic adds a component to a message at 
the next available index. The component is placed in the message body 
bv the process of polymorphic streaming (by caihng template <class 
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AType> vcd Flatten (const AType^.TStream^) ). ,t returns the ,ndex at 
vvhicn me component is placed. 

The runccon AddMonomorph.c adds a component to a message 

- bodv by the process or monomorph.c streammq (bv callmg 

AT>^.:operato.»=). u returns the mdex at ^h.h the component . 

The runctzon GetPoIvmorph.c retrieves the component m 
message at mdex as an object of AType. If the component m message 
) ot d:fteren: type, this runct.on throws TTypeM.match exception 

The runction GetMonomorphic retrieves the component in 
message at mdex as an ob,ect ot AType. If the componen't in message is 
ot difterent type, this function throws TTypeMismatch exception 

Anotner class is related to message properties. This .s the 
TMessageAddressBundle class which represents an entitv to which a 
message can be sent. Since an address is needed for sendmg a message 
the TMessageAddressBundle class is constructed from a message 
receiver address and related attributes as noted m Table 19 below 
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Table 19 



VI ulti- thread -sate 


No 


Surrocate Vaiue-iike 


Value-like 


\! ult!-mstance-sare 


Ye? 


Allows mheruance 


No 


Static-sar'e • 


N<^ 


Aliocanon - stack. heao 


Both 


Shared -memorv-sa re 


No 


Abstract / Concrete 


Concrete 



inhents From: 

VtReterenceCounted 

Constants. Enumerators. TVpes: 
enum 

EKind (kTo kCC. kBCC. kFon^-ardTo. kf rom. KFonvardFrom. kReoivTo 
^Recipient. kAili ^.w-ivi^^. 

Member Fur.cnons: 

TMessaeeAddressBundie (const 

TCountedPomterTo<TMessageReceiverAddress><^ address EKind 
kmo = kTo) ' 

TVIessaceAddressBundle CTStrcam<ic rromVVheret 
TMessaceAddressBundle () 

• TCountedPointerTO<TMessageReceiverAddress> 
Get Address (J const 

• EKmd 
GetKjnd ( ) const 

• bool 

IsValid 0 const 



The enumerator EKind reflects an attribute to qualifv a receiver 
30 address. These can be logically "OR'd" together to form a filter tor use 
m address iteration. One attribute is "kTo" which means a primary 
target of a message. .Mother attribute is "kCC" which means a 
secondarv target of a message. In addition. kBCC is a blind secondary 
target of a message. kPorwardTo is a forwarding target of a messa^e. 
35 kFrom is the originator of a message. kForwardFrom is the address 
from which a message was forwarded. kKeplvTo is an address used 
when replying which defaults to kFrom address. kRecipient is a 
predefined filter for (kTo kCC - kBCC * kForwardTo). kAIl is a 
predefined filter w^hich will match anv kind. 

The function TMessageAddressBundle constructs a bundle object 
with the specified address and kind. Alternatively, it constructs a 
bundle object by streaming data from the stream from Where. 
Alternatively, it creates an invalid bundle. Such a bundle is useful for 
future assignment. A null bundle in a draft message is icnored. 
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The function GetAddress returns the address ror this bundle 
Also, the runction GetKind returns the kind attribute for this bundle 
In addition, the runction IsValid returns true if the bundle has a valid 
address. 

-Another class related to message properties is the 
TN4essageAddressIterator class (not shovvn.'which provides an iterator 
over the addresses in a message as noted in Table 20 below. 



10 



15 



20 



30 



40 



Baiic -Attributes: 



Table 20 



\I ulti-thread-sate 


\=o 


Surroeate /Value- like 


Value-like 


\Iulti-instance-sare 


Yes 


Allows- inheritance 


No 


Staric-safe 


!Sjo 


Aliocanon - srack.heac 


Both 


^hared-memorv-sare 


No 


Abstract /Concrete 


Concrete 



Inhents From: 
-\one 

Member Funcnons: 

TMessaeeAddresslterator iconst T.VIessaeei. messae;e 
I .MessageAddressBundie::EKind5et niter := kTo) 

T Vies sage Ad dress iterator () 

• v.rtual TMessageAddressBundie 
First f) const - 0 

• v irtuai TMessageAddressBundie 
Next (J const = 0 

rod 

v^Derator== ; 



tor== iconst TMessageAddressi teratori: riehn const 



r'ool 



operator!= (const TMessageAddressIteratori rightl const 

The TMessageAddressIterator function creates an iterator over 
the specified message with the specified filter. Altemativelv is may 
create an invalid iterator which can be reserved for a future assignment. 

The First function returns the first address in this message" If the 
bin IS empty, an invalid TMessageAddressBundie object is returned. 

The Next function returns the next message in this bin. If the bin 
is empty, an invalid TMessageAddressBundie object is returned. 

The operator== and operator!= functions are equalitv (inequalitv) 
checks for two iterators. They return a true if both iterators refer to the 
same message, have the same filter, and have the same iteration 
'position'. 
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Some general items to note are that subclass Application 
Programming Interface { API) classes are not needed to use the 
messaging interface classes. The messagmg interface API is built on top 
or a messaging rramevvork. The rramework requires subclassing or a set 
5 of classes to plug-in a service provider. 

Tne messaging interface API does not guarantee delivery of a 
message. Different service-providers may have different level of 
delivery guarantees. Some messages may be delivered with loss of data. 
Tne messaging API defines a message type that will not suffer anv 
10 transformation when delivered to a CommonPomt^^' recipient 

(TCommonPointiMessage class 728). There is a type of message which 
imposes no constraints on the contents or recipients 
fTlnterOperableMessage class 730). However, the messaging interface 
API makes no guarantees about the mtegritv or instances of the 
15 TinterOperableMessage class 730. 

Both TCommonPointMessage class 728 and 
TinterOperableMessage class 730 support multiple components of any 
type, as long as the type has the CommonPoint'^'''' t\rpe extensions. 
Instances (i.e., objects) of the TinterOperableMessage class 730 may drop 
20 the components that can not be translated appropriately. 
By iterating over component tvpes using 
TMessage::GetComponentType, contents of a message can be 
determined. In addition, the e.xistence of a specific tvpe of component 
<say text) can be checked by usmg TMessage::DoesContainType. 

The messaging interface API does not provide anv direct means 
other than construction or reading of received messages for obtaining 
receiver addresses. The goal is to have receiver address manufactured 
bv other objects such as people or business cards, etc. 

Client applications may use service-provider-specific address 
30 classes (e.g., the TlnternetReceiverAddress class 722) bearing m mind 
that it results in routing a message to that address through onlv given 
service-provider. 

To keep the different aspects of storage behavior separate from 
each other several bin classes are provided. For example, the 
35 MMessageStore class 702 provides writmg behavior (create or copy a 

message m to) ror a bin, while the MMessageSource class 704 provides 
reading behavior (iterate over contained messages). This kind of 
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::rsr:e:it:s" -------- ^3.0.3 ........ 

Th,s separation of behav.ors . stnctiv enrorccd. For examole 
MMessageStore provides wnte-onlv protocol to message bm It^^ m 
. break the wnte-oniv behav.or to prov.de wa.t tor o Z^^^^T'" 
th,s class. Thus, it ,s not possible to wa.t for (, e kev of f o 
arru-al at a MMessageStore object. "^^^^^^ 
The foIJowmg example shown m Table 21 illustrates the use of 
baMC tunctionahtv provided bv the messa^mg .nterface. 
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■ Table 21 

SRevision I 2 i 
Messcieintrj.imples.C 

Copv-ncm C 1^*95 Tail Rcm. Inc. Ail nenrs res^rvcc 

Iri oraer lo tcKus on tt\e Messaemc ATI i, itjs rrocTAm uses a rradinon.!! 
C srvic vs-itn a rrusLH ana liiobai tuncDons 
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^imder Tabcent .NtESSAGZVC 



— »ixicJude < rabeent/ Messaeing.n> 

i D •cndu 



Jimdei Taueeni. LVTERiN.TTRECErS.'ER.^DDRESS 
■nncludf '.Tdiicent/ IntemetKeceiverAddrcs* jiv 

•CTKlU 

*irnoe : T .ih een t . DOC \J\\ E NTSTO R ECONT E NTST R E AM E R 
^induUo < T*\Lieent/OocurncTiotoreConrenoiTeamer.r.> 

»irnde! TdliGer.t.SAMTLEPROCEDUREMAPS 
»incJuOe < Tdhecnt/ bampieProcedureMaps.h> 
•endii 

-imde: TabBent_EXCEmON:FORMATTER 
^-jTcluae <TAi!eeni/ hxceoDcni-ormatttr h> 
aendi; 



*\mdc: T.ilicer.: MULTIPLEKOOTLOCATOR 
=ir.ciude TAucent/ Muinrie Root Locator. n.-> 
J 3 =enciu 



>rimdei T.ilicent^BASICDOCL'MENTSTORAGc 
mciude <T.\iicen!/ Basic DoojrTiencDtoraee.n> 
*endi: 



Message Sending FuncDOns 



' Sena a messaee contaimnc rex: onlv The messape can be read withon almost 
anv mail svstem on anv n»?5t. Text svles will be stripped and some ioss of 
text TUAv occur due to cnaracter set rransianon: 



-n " '^^'^ SenalnrercrcrableText -.c.^asi TCounredrointerTo<TMes!weeRecetver Addj'ess>4f 

address. 

const TSt.mdardTextAt subieci. 
const TStanc:ardTe*tAf texti 

-- TLnieroDeracieMessaee me^saceis ubtect. ad dress tcx 1 1 ' Make messaev 

'^'Messacer^p.aer-CetDera^jitzrjenaeri i->:5uorrut<mes5acci. .' ,- Sjomj; 



60 



' ■ Send d message coniaimnc text oniv The message can orvJv be rcaa witAui 
■ CommonPomt-^'' 

void SendCommorxPointTeu iccnsi TCountedPointerro<TMessa(!eRecei\-erAddress>i address 
const TTexti: iubiect. 
const TStancardTexiA text) 



•'^ote TStandardText coiects should normAllv r-e handled ustnc 

AdKlMonomorpmc and L.etMonomorphtc runcaons. Poivmorphic hand line 
IS nredJesslv exper\st\*e 

-rn TCommonPointMessa^e messa^eisubtect -address); Make message 

.-^ppencLMonomorphicfmes&aee.te.xtj: ■' ^ Add the te^xi. 

LMessaeeSend er<;elDerauit=^der(t->Subrrut( message I ; // Submit 



SO 



'.■ Send a messaee comauunc a smele Common f 'oint obiect. T>.e message can oniv 
■ ' be reaa withun ComjnonPcmi * 

template <cJass aTvt^> 

void SendOneObteci iconst TCounrrdromterTo<TMes&ace Receiver Address >e< rtddres.v 
const TTejti^ sucnect. 
corvst AType^ ocnect) 

TCommoT\PotniMessage mevsaeetsubieci^ddressi. // Make mess^ee 

Append Pol vmorphic^meisaee-ooiect). . / Add the object. 
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^lNi«s.ceiender:.CctDer.ultiend.rO->buDmi.,messaee,. ■ Submit 

- ' ^ena a rr.essace containinc three C ommon Point ■ ^ oh,^r,c t- 

/ / be read w:min CommooJ'omt- message ca^ 



onjv 



lemoiare <cJass ATvpe, ci^is BTvpe. cla« Crvpe> 

10 ^ndTh/eeObiectstconst TCouniedPomterro<TMessaeeRecen er AHHr^c-.^ ^ 

^ coast TStanaardTe.ific subject. ^^^eKecen er Add/ess>Ac acdresi 

const ATypeit obiectl. 
const BTvpe& ob)ect2. 
^ const CTypeac obicct3) 

^'^^"^of^uintMessage messape<sub,ect^ddress) / - vi., 

AppendrolvmorphiC,me5S3^e.ob,ectl I: / , Add th/nn 

A ppendPolvrnGTOhm messaee.obiecU 1 
20 . ^'•^'"^^^'*'^^^'"-^^*'t^^^"»^'^"<>->i'"bminmessaee;. Sunm:t 



Messace E.xaminanon Hunccons 

/ 



•/ Scan message and r^tun. rrx^e ti, contains a component o» the srecmcd n^e: 

boci DoesMessaceContam (const TMessaerRetermce& message 
3Q ^ '^o'^t 'n'vpe:>urTogave<ic tartjetlvpe) 

booi lound - talse: 

:oT t'jr.xi = 0 i < message. Coun.-Componcntsf i. r-- t 
u •nr»essace.isComponentrvpe(iarKet7 vpe.iK 



lound = true; 
oreak. 



rerum lound. 

! 

i :' >can messace and pnnt alJ text components: 
v oid PnntTextComponents (const TMessageReterenceit message, 
TStandArdTevt text. 

TT-.-pcaurrocMe tettTypeiStancTv-pelntorrStandardText) > 
^.^mooncntinaex count =x messa«;e.CountComt>onentsO: 
:<-^r ( LT.t 1 = iJ : < count: i** i 

u ' messace. UComDoncmTvptjitfxi I vpe.in 

CetMonomorphictmessaee.text .i; // Extract text from mess^gn 
OPnntT€Tt(texi); // Pnnt it. 



' S?na and Receive Messages 



70 ^ " 

const TStandardTexiflt textbodv, 
const TTexiAc cpSubiect. 
const TdocumentReferencc^ document, 
const TTimeit ame. 
const TProceOureMapfie map) 



Send an mreroperable text message... 

SendinteroperableTexttaddress.tex^ubiect . text Bod V): 
Send a text obiect... 

<€ndCommonPointTexiiaddress.textSubtect.textBodvi; 



85 . * messace conramme a single CommonPomt ob^^ci (a document 

reference I... 
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ncndOneObiecii address. CP suoiect.'docu mem ». , 

. >end A mesMite coniaininc a smcle CommorvJ^oint cbieci ipi document 
• bv vrtlue! . 

^ndOneC'necitadOress.rpiubicctTDoc^imenotoreConieTicirTeameridocijnien:). 

*' Send a message coniaimne ihrec CorT\monl'oint ooiects.. 
^cn d Th reeC'Oi ts I ad dj es s . q? Su Dice t.d ociJ rn e n t. time ,ma p I ; 

Wait tor the messages tc be recievec. F:rs:. tjet 'jnc receiver 
■ ' irtstancc. 

TCoiintedrcin!erro<MMcssaeeReceiver> receiver = address ->C>tMessaeeRecer 

' Now i(>cD wrtituic unrJ we recieve the messii(;e contairunt; 
3 TProcec-jreMap... 

boo! Jone = raise. 

TT vpeburroeate map T ypet Stand ypein/orTFroced ureMap) »: 

T.MessaireReierence received Message: /. Starr with an uivabd messaize 

while (! dono' 

/ VVajI icr A new messa*;*' to arrive.-. 

receivedNJessace = receiver >WaitforMessaeeAitenrece:vedM(ssaee). 

/ Prm; j.r»v" te,\i com Done nts in the messaec 

Pnr.tl e\rJ.onponentsireceivedMes5afi;ei. 

Termin.Are wnen we ve reoevcd ine message containing tnree 
*/ obiec3. one oi wmch 13 a document... 

It (receu edMessage.CountComponcntso == :m 

f 

done = DoesMessaeeContamircceivedMessaee-maprype!; 



M^un 



For simDiiv::r\ ue Assume mat this procram is entered trom tne commanc 
line, and ir.at ;t is pASsea a smcie artrumcnt wmch is rreateu as an 
Internet fr. ie maii address Ail other data is nara -coded - 

NorTTLaltv should be retrieved rrom eiL^er .i business card or rrcm 

Lne Q tree re- services 



mt mainiint arcc. cnar'ar^r^-j }» 
bool trilled ■= targe != 
jt (! faiied! 

TOn]vPcinterTo<TDocumencitorc> store: 
TC>ravPointeTro<TSianaArdStorageMe<:haAism> mec^\anism. 



/ .' Make in internet address... 

TCountedPomterTo<T7v.»essaeeReceiverAddress> address = 
new TlntemetRecetvcrAadressfTStandardTexndJKv( 1 1)>. 

' / Make up the remaining arguments to Messa gxnpS Ample s... 

TStandardText textSubtectrTexi Enclosed. 1. 

TS land ATd Text texiBodv(This is a text nYes&aee rrom CommonFoint !. 
TStanaardTe-xt cuSubiectC'CommonPoint Obiects Enclosed, i. 
TScconos tirr«(1234); 
TMarbleProcedureMap map; 

// Get a rDocumeriLReiercnce... 

TMulacieRoot Locator locatorC'Places 1: 

TEXrectorv nomePlace = locator. Fmd First BvNamcrDe /a uh User HomePJace J. 
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store = new r Document tore* mec/iarusm.OrDnanO I -^""i^i^ 
rCXx-omentKetercnce uocument ^ srorr- >Ce.U>cumeniKt"rcr^ce, !. 

Now execute the samples.. 
^'^^•"*^.^n.o.esMddress.texouNect.te.xt8cKlv.cp:.ub,eci.aocument.n^^^ 
catch icoa<;t TStandardLxceptioncf e.TceoDoni 



laiied = true: 
TStandaxdText messaec. 

15 ■^^^'o'^^'»edTexuc.xceprion.TLocd(e..(.;e^ 

message). 

OPrini Tex ti message;. 



tiJeo - true; 

OrV-itTexKIStAnaardTextC^T. unknown exception w^.s caupht.")). 



0!'nn.TeM(TStanddrdText( Invalid are^ments. Use. Messa^ingSamples 
address )J, 



30 

rerum laiJed 1 0. 
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The present invention can be summarized in reference to FIG. 12 
which IS a flowchart of the preferred embodiment object oriented 
programmmg based messagmg interface method for use between a 
client application and a messaging service on a computer svstem. This 
method IS performed by device-implemented steps m a series of distinct 
processing steps 1200-1212 that can be implemented ,n one or more 
40 processors. 

A message class 724 is provided 1202 which has data members 
and member functions related to a message in the messagmg service. In 
addition, a message bin class 700 is provided 1204 which has data 
members and member functions related to holding the message. Also, 
a message bin name class 716 is provided 1206 which has data members 
and member functions related to identifying a message bin object 
instantiated from the message bin class 700. Subsequentlv, a messaging 
interface object for the message is generated 1210 as an instance of one of 
these provided classes (i.e.. the message class 724, the message bin class 
700, or the message bin name class 716. This messaging interlace object 
provides the client application with protocol independent access to the 
messagmg serv ice. 

Other classes may be provided 1208 prior to the generating step 
1210 such that other messaging interface-related objects can be generated 
in the generatmg step 1210. For example, a message address bundle class 
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mav be provided 1208 vvhich has data members and member runctions 
related to a message receiver address to which the message can be sent 
in the messaging service and related attributes of the message receiver 
address. In addition, a message address iterator class mav be provided 
1208 vvhich has data members and member functions related to an 
iterator over the addresses. 

A message reference class 712 may be provided 1208 vvhich 
inherits all of the data members and member funchons defined by the 
message class 724. It further defines data members and member 
functions related to locking the message such that the message can not 
be modified. 

A draft message class 726 may be provided 1208 which inherits all 
of the data members and member funchons defined bv the message 
class 724. It further defines data members and member functions 
related to data integritv and interoperability of the message. Further, an 
OOr-specific message ciass 728 may be provided 1208 which inherits all 
or the data members and member functions defined by the draft 
message class 726. It further defines data members and member 
functions related to guaranteeing data integrity when delivering the 
message to an OOP-based message system. Furthermore, an 
interoperable message class 730 may be provided 1208 which inherits all 
or the data members and member functions defined bv the draft 
message ciass 726. It further defines data members and member 
functions related to guaranteeing data interoperability when delivering 
25 the message to a non-OOP-based message system. 

A message store class 702 may be provided 1208 which inherits all 
or the data members and member functions defined bv the message bin 
ciass 700. It further defines data members and member functions 
related to protocols for storing the message into a message store object 
0 instantiated from the message store class 702. Further, a message sender 
class 706 may be provided 1208 which inherits all of the data members 
and member functions defined by the message store ciass 702. It further 
defmes data members and member hinctions related to protocols for 
submitting and sending the message from the client application to the 
5 messagmg service. In addition, a message source class 704 may be 
provided 1208 which inherits all of the data members and member 
functions defined by the message bin class 700. It further defmes data 
members and member functions related to protocols for retrieving the 



20 



SUBSTITUTE SHEET (RULE 26) 



10 



15 



20 



30 



wo 97/22928 

PCT/US96/20S36 

-48- 

message from a message source obiect mstant.ated from the message 
source class 704. Th.s allows a fUe system message store class 714 to be 
provided 1208 wh.ch :nherus all of the data members and member 
tunct.ons defmed by the message sender class 706 and the 
0 MMessageSource class 704. It further defmes data members and 

member tunchons related to protocols for stormg, accessmg and sendme 
the message where the message .s stored m a fUe svstem dxrectorv m a 
storage device 120 of the computer svstem. 

A message source class 704 alone (i.e.. without the message 
sender class 706 and the message source class 704) mav be provided 1208 
which inherits all of the data members and member 'hancttons defmed 
bv the message bin class 700. It harther defines data members and 
member functions related to protocols for retnevmg the message from a 
message source object instantiated from the message source class 704 
rurther. a message receiver class 708 mav be provided 1208 which 
innents all of the data members and member functions defmed bv the 
message source class 704. It further defines data members and member 
runctions related to protocols for receiving the message at a receiver 
address from the messagmg service and providmg the message to the 
Client application. Alterr^atively, a message iterator class 710 mav be 
provided 1208 which has data members and member functions ;elated 
to Iteration tunctionalitv over a collection of messages from a message 
source object instantiated from the message source class 704. 

A file svstem message store name class 714 mav be provided 1208 
-men inherits all of the data members and member func'tions defmed 
bv the message bin name class 716. It further defines data members and 
member tunchons related to identifying a file svstem message store 
ODject instantiated from the file svstem message store class 714 

A MessageRece.verAddress class 718 mav be provided 1208 which 
inherits all of the data members and member funchons defmed bv the 
message bm name class 716. It further defines data members and' 
member functions related to identifymg a message receiver object 
mstantiated trom the message receiver class 708. Also, a internet 
receiver address class 722 may be provided 1208 wh.ch inherits all of the 
data members and member functions defined bv the 

MessageReceiverAddress class 718. It further defmes data members and 
member functions related to identifying an RFC-S22 compliant Internet 
mailbox address. 
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This messaging intertace process may be implemented in a 
computer system bv storing the classes m a storage device 120 and using 
a processor 110 in conjunction with RAM 114 and /or ROM to generate 
objects from the stored classes. A communications adapter 134 mav 
communicate a message object, instantiated from the message class 724, 
between the computer system and other computer svstems operatively 
coupled together on a communication network. 

In addition, a program storage device may be created wmich is 
readable by a computer system tangibly embodying a program of 
instructions executable by the computer system. This program of 
instructions would perform one or more parts of the object oriented 
programmmg based messagmg interface method described about. 

It is to be understood that even though numerous characteristics 
and advantages of various embodiments of the present invention have 
been set forth m the foregomg description, together with details of the 
structure and function of various embodiments of the invention, this 
disclosure is illustrative only, and changes mav be made in detail, 
especially in matters of structure and arrangement of parts withm the 
principles of the present invention to the full extent indicated by the 
broad genera: meaning of the terms in which the appended claims are 
expressed. For example, the actual names or ciivision or functions may 
be changed between the OOP classes and objects, detailed above, while 
maintaining substantiallv the same functionalitv without departing 
from the scope and spirit of the present invention. 
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Claims 



^Vhat is claimed is: 



An object onented programming (OOP) based messaging 
mterrace method for use between a chent appl.cafon and a 
messagmg service on a computer svstem, comprising the steps or 
(a.) prov.dmg a message class which has data members and 
member tuncnons related to a message ,n the messaging 
service; ^ ^ 

(h) providmg a message bm class which has data members and 
member functions related to holding the message- 

(c) providmg a message bm name class which has data 

members and member functions related to identirvmg a 
message bin object instantiated from the message bin dass; 
and 

id) generatmg a messaging interface object for the message as 
an instance of one of the provided classes, the messaging 
mterface object furnishing the client application with 
protocol independent access to the messagmg service. 

The messagmg interface method of claim 1 further comprising 
the step or providing a message address bundle class which has 
data memoers and member functions related to a message 
receiver address to which the message can be sent in the 
messagmg service and related attributes of the message receiver 
address. 

The messaging interface method of claim 1 further comprising 
the step Of providing a message address iterator class which has 
data memoers and member functions related to an iterator over 
the addresses. 
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4. The messaging interrace method or claim 1 further comprising 
the step of providing a message reference class which inherits all 
of the data members and member functions defined bv the 
message class and further defines data members and member 
functions related to locking the message such that the message 
can not be modified. 

X The messaging interface method of claim 1 further comprising 
the step of providing a draft message class which inherits all of 
the data members and member functions defined by the message 
class and further defines data members and member functions 
related to data integrity and interoperability of the message. 

rv The messaging interface method of claim 5 further comprising 
15 the step of providing an OOP-speafic message class which 

inherits all of the data members and member functions defined 
by the draft message class and further defines data members and 
member functions related to guaranteeing data integrity when 
delivering the message to an OOP-based message svstem. 



10 



20 



30 



j>3 



The messaging interface method of claim 5 further comprising 
the step of providing an interoperable message class which 
inherits all of the data members and member functions defined 
bv the draft message class and further defines data members and 
member functions related to guaranteeing data mteroperabilitv 
when delivering the message to a non-OOP-based message 
system. 

The messaging interface method of claim 1 further comprising 
the step of providing a message store class which inherits all of 
the data members and member functions defined by the message 
bin class and further defines data members and member 
functions related to protocols for storing the message into a 
message store object instantiated from the message store class. 
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V. The messaging interface method ot claim 8 further comprising ■ 
the step or providing a message sender class which inherits all of 
the data members and member functions defined bv the message 
store ciass and further defines data members and member 
5 runctions related to protocols for submitting and sendmg the 

message rrom the client application to the messaging service. 

10. The messaging mterface method of claim 9 further comorismg 
the steps of: 

^^'> providing a message source class which inherits all of the 
data members and member functions defined by the 
message bin class and further defines data members and 
member functions related to protocols for retrieving the 
message from a message source object instantiated from 
tbe message source class; and 
(b) providing a file system message store ciass which inherits 
all of the data members and member functions defined by 
the message sender class and the message source class and 
further defines data members and member functions 
reiated to protocols for stormg, accessing and sending the 
message where the message is stored in a file svstem 
directory in a storage of the computer svstem. 
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The messaging interface method of claim 1 further comprising 
the step or providing a message source ciass which inherits airof 
the data members and member functions defined by the message 
bin ciass and further defines data members and member 
functions related to protocols for retrieving the message from a 
message source object instantiated from the message source class. 

The messaging interface method of claim 11 further comprising 
the step or providing a message receiver class which inherits all 
of the data members and member functions defined by the 
message source class and further defines data members and 
member runctions related to protocols for receiving the message 
at a receiver address from the messaging service and providing 
the message to the client application. 
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13. The messaging interface method ot claim 11 further comprising 
the step or providing a message iterator ciass which has data 
members and member functions related to iteration functionality 
over a collection of messages from a message source object 

5 instantiated from the message source class. 

14. The messaging interface method of claim 10 further comprising 
the step of providing a file system message store name class 
which mherits all of the data mf.'mbers and member functions 

10 defined by the message bin nama class and further defines data 

members and member functions related to identifying a file 
system message store object instantiated from the file system 
message store ciass. 

15 15. The messaging interface method or claim 12 further comprising 
the step ot providing a message receiver address ciass which 
inherits all of the data members and member functions defined 
by the message bin name class and further defines data members 
and member functions related to identif\'ing a message receiver 

20 object instantiated from the message receiver class. 

16. The messaging interface method of claim 15 further comprising 
the step of providing a internet receiver address class which 
mherits all of the data members and member functions defined 
-5 ti]^* the message receiver address class and further defines data 

members and member functions related to identifving an RFC- 
S22 compliant Internet mailbox address. 
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ir. A program storage dev.ce readable bv a computer svstem tane.blv 
embocvmg a program or instructions executable bv the computer 
svstem to perform an object onented programming (OOP) based 
messaging mterrace method for use between a client application 
and a messaging service on the computer svstem, the method 
comprising the steps of: 

(a) providing a message class which has data members and 
member functions related to a message in the messagme 

service; ^ ^ 

1^'^ fb> providing a message bu. class which has data members and 

member tunctions related to holding the message- 
(c; providing a message bin name class which has data 

members and member functions related to identifying a 

"T'^' "^'"^^ mstannated from the message bin class- 

and ^ 

(d) generating a messagmg interface object for the message as 
an instance of one of the provided classes, the messaging 
mterrace object furnishmg the client application with 
protocol independent access to the messagmg service 



20 
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20. 



The program storage device of claim 17 wherein the method 
rurther comprises the step of providing a message address bundle 
class wnich has data members and member functions related to a 
message receiver address to which the message can be sent in the 
messaging service and related attributes of the message receiver 
address. 

The program storage device or claim 17 wherem the method 
further comprises the step ot providing a message address iterator 
class which has data members and member functions related to 
an Iterator over the addresses. 

The program storage dev.ce of claim 17 wherem the method 
further comprises the step of providmg a message reference class 
wmch inherits all of the data members and member functions 
defined bv the message class and further defines data members 
and member tunctions related to locking the message such that 
the message can not be modified. 
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21. The program storage device or ciaim 17 wherein the method 
further comprises the step of providing a draft message class 
which mherits ali of the data members and member functions 

5 defmed by the message class and further defines data members 

and member functions related to data integritv and 
interoperability of the message. 

22. The program storage device of ciaimt 21 wherein the method 

10 further comprises the step of providing an OOP-specific messag 

class which inherits all of the data members and member 
functions defined by the draft message class and further defines 
data members and member functions related to guaranteeing 
data integntv when delivering the message to an OOP-based 

15 message system. 



23. The program storage device of claim 21 wherein the method 

further comprises the step of providing an interoperable message 
class which inherits all of the data members and member 
^0 functions defmed by the draft message class and further defines 

data members and member functions related to guaranteeing 
data interoperability w^hen delivering the message to a non-OOP- 
based message svstem. 

25 24. The program storage device of claim 17 wherein the method 
further comprises the step of providing a message store class 
which inherits all of the data members and member functions 
defined by the message bin class and further defines data 
members and member functions related to protocols for storing 

-^'3 message into a message store object instantiated from the 

message store class. 
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The program storage device of cla.m 24 where.n the method' 
further comprises the step of providmg a message sender class 
whxch inhents all of the data members and member functions 
defined dv the message store class and furrher defmes data 
members and member functions related to protocols for 
submittmg and sendmg the message rrom the client application 
to the messaging service. 

The program storage device of claim 25 wherein the method 
further comprises the steps of: 

(a) providing a message source class which inherits all of the 
data members and member functions defmed bv the 
message bin class and further defmes data members and 
member functions related to protocols for retrieving the 
message from a message source ob,ect instantiated from 
the message source class; and 

(b) providing a file system message store class which inherits 
all of the data members and member functions defined by 
the message sender class and the message source class and 
further defines data members and member functions 
related to protocols for stormg, accessing and sending the 
message where the message is stored in a file svstem 
directory m a storage of the computer system. 

The program storage device of claim 17 wherein the method 
further comprises the step of providing a message source class 
which inherits all of the data members and member functions 
defined by the message bin class and further defines data 
members and member functions related to protocols for 
retrieving the message from a message source object instantiated 
from the message source class. 
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The program storat;e device or claim 27 wherein the method 
airther comprises the step of providing a message receiver class 
which inherits all of the data members and member functions 
defined by the message source class and further defines data 
members and member functions related to protocols for 
receiving the message at a receiver address from the messaging 
service and providmg the message to the client application. 

The program storage device of claim 27 wherein the method 
njrther comprises the step of providing a message iterator class 
which has data members and member functions related to 
Iteration runctionaiity over a collection of messages from a 
message source object instantiated from the message source class. 

The program storage device of claim 26 wherein the method 
further comprises the step of providing a file system message 
store name class which inherits all of the data members and 
member functions defined by the message bin name class and 
further defines data members and member functions related to 
identif\ang a file system message store object instantiated from 
the file system message store class. 

The program storage device of claim 2S wherein the method 
rurther comprises the step of providing a message receiver 
address class which inherits all of the data members and member 
functions defined by the message bin name class and further 
defines data members and member functions related to 
identifying a message receiver object instandated from the 
message receiver class. 



The program storage device of claim 31 wherein the method 
further comprises the step of providing a internet receiver 
address class which inherits all of the data members and member 
functions defined by the message receiver address class and 
^5 further defines data members and member functions related to 

identifying an RFC-S22 compliant Internet mailbox address. 
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An object oriented programming (OOP). based messa^ma 
mterrace between a client application and a messagmg serv.ce tor 
a computer system, comprising: 

(a) a storage device, in the computer system, which stores 
OOP-based classes, the classes, including: 

(i) a message class which has data members and 
member functions related to a message in the 
messaging service; 

(ii) a message bm class which has data members and 
member functions related to holding the message; 

(iii) a message bm name class which has data members 
and member runctions related to identifying a 
message bin ob.ect mstanhated from the message 
bin class; and 

fb) a processor, operativeiy coupled to the storage device, 
which generates a messagmg interface object for the 
message as an instance of a class stored m the storage 
device, the messaging interface object furnishing the client 
application with protocol independent access to the 
messaging service. 

The messaging interface of claim 33 further comprismg a 
communication adapter, operativeiy coupled to the processor, 
which communicates a message object, instantiated from the 
message class, between the computer system and other computer 
systems operativeiy coupled together on a communication 
network. 

The messaging mterface of claim 33 wherem the storage device 
further mcludes a message address bundle class which has data 
members and member functions related to a message receiver 
address to which the message can be sent in the messaging 
service and related attributes of the message receiver address. 
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36. The messaging interface of claim 33 vvherem the storage device 
further includes a message address iterator class ^vhich has data 
members and member functions related to an iterator over the 

addresses. 

37. The messaging interface of claim 33 wherein the storage device 
further includes a message reference class which inherits all of 
the data members and member functions defined bv the message 
class and further defines data members and member functions 

10 related to locking the message such that the message can not be 

modified. 



38. The messagmg interface of claim 33 wherein the storage device 
turther includes a draft message class which inherits all of the 

15 data members and member functions defined bv the message 

class and further defines data members and member functions 
related to data integrity and interoperability of the message. 

39. The messaging interface of claim 38 wherein the storage device 
20 further includes an OOP-specific message class which inherits all 

of the data members and member functions defined bv the draft 
message class and further defmes data members and member 
functions related to guaranteeing data integrity when delivermg 
the message to an OOP-based message svstem. 

25 

40. The messaging interface of claim 38 wherein the storage device 
further includes an interoperable message class which inherits all 
of the data members and member functions defined bv the draft 
message class and further defines data members and member 
functions related to guaranteeing data interoperability when 
delivermg the message to a non-OOP-based message system. 



30 



41. The messaging interface of claim 33 wherein the storage device 
further includes a message store class which inherits all of the 
35 data members and member functions defined bv the message bin 

class and further defines data members and member functions 
related to protocols for storing the message into a message store 
object instantiated from the message store class. 
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The messaging interface or" claim 41 wherein the storage device 
further includes a message sender class which inherits all of the 
data members and member functions defined bv the message 
store class and further defines data members and member 
functions related to protocols for submitting and sending the 
message trom the client application to the messaging service. 

43. The messaging interface of claim 42 wherein: 

'^°^^8^ f""her includes a message source class 

vvmch inherits all of the data members and member 
functions defined by the message bin class and further 
defines data members and member functions related to 
protocols for retrieving the mejssage from a message source 
obiect instantiated from the message source class; and 
(b) the storage device further includes a file svstem message 
store class which inherits all of the data members and 
member functions defined by the message sender class and 
the message source class and further defines data members 
and member functions related to protocols for storing, 
accessing and sending the message where the message is 
stored in a file system directory in a storage of the 
computer system. 
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The messagmg interface of claim 33 wherein the storage device 
turther includes a message source class which inherits all of the 
data members and member functions defmed bv the message bin 
class and further defines data members and member functions 
related to protocols for retrieving the message from a message 
source object instantiated from the message source class. 

The messaging mterface of claim 44 wherein the storage device 
further includes a message receiver class which inherits all of the 
data members and member functions defined bv the message 
source class and further defines data members and member 
functions related to protocols for receiving the message at a 
receiver address from the messagmg service and providing the 
message to the client application. 
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46. The messaging interface of claim 44 wherein the storage device 

further includes a message iterator class which has data members 
and member functions related to iteration functionality over a 
collection of messages from a message source object instantiated 
from the message source ciass. 

The messaging interface of claim 43 wherein the storage device 
further includes a file system message store name class which 
inherits all of the data members and member functions defined 
by the message bin name class and further defines data members 
and member functions related to identifying a file system 
message store object instantiated from the file svstem message 
store class. 

The messaging interface of claim 45 wherein the storage device 
further includes a message receiver address class which inherits 
all of the data members and member functions defined by the 
message bin name class and further defines data members and 
member functions related to identifying a message receiver object 
instantiated from the message receiver class. 

The messaging interface of claim 48 wherein the storage device 
further mciudes a internet receiver address class which inherits 
ail or the data members and member functions defined bv the 
message receiver address class and further defines data members 
and member functions related to identifying an RFC-822 
compliant Internet mailbox address. 
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